add preselection property to (almost) all CP algorithms
At the last ASG meeting it was discussed to allow filtering on a preselection decoration in the common CP algorithms (instead of relying on view containers). So I now went ahead and added this to all of the common CP algorithms that work on individual objects. Not all of them will necessarily need one, but since we do allow users to do a pt-eta preselection before the CP algorithms are run it is probably good for all algorithms to have. Basically you can now do something like:
alg = createAlgorithm( 'CP::AsgSelectionAlg', 'MuonKinSelectionAlg' )
alg.selectionDecoration = 'kin_select,as_bits'
...
alg = createAlgorithm( 'CP::MuonCalibrationAndSmearingAlg', 'MuonCalibrationAndSmearingAlg' )
alg.preselection = 'kin_select,as_bits'
...There are a couple of algorithms that operate on containers instead of objects, and I haven't touched those (yet). Mostly because there are multiple options to do so: I could conceivably create a view container on the fly and feed that as an input into the tool. Or add a preselection property to the tool itself, or in the case of the overlap removal tool update the existing property to use an ISelectionAccessor instead. Or, maybe we shouldn't do any filtering because the tool is meant to operate on all the objects, not just the "good" ones. I'm happy to add whatever people want, but I need some guidance on how to proceed for each algorithm.
I also didn't update any of the configuration files at all. I rather leave that to the CP and/or configuration experts, or at least to a separate merge request. It ought to be fairly straightforward, essentially just take the accumulated selection decorations and put them into the preselection property of each algorithm. If we want to go this way, we should almost definitely update all sequences to use this preselection mechanism instead of view containers, otherwise we just added this complication to the algorithms for nothing. I just didn't want to do it in this MR, and preferably wouldn't do it myself.
To make the implementation easier I added a SelectionReadHandle. While this doesn't contain any complex logic (like the systematics handles) it does cut in half the number of lines I need to add to each algorithm, which is still helpful for something that is used by a few dozen algorithms. Plus it provides a common point for refactoring in the future (should we need it).