split CP algorithm sequence configuration into three parts

Essentially the idea here is that this makes it easier to build additional configuration layers on top, since it makes this more composable. In particular it means that multiple working points can be added to a single sequence without having to do some complicated special handling to deduplicate the calibration part of the sequence. I also purposely pass in the actual sequence I operate on instead of creating them internally, which (hopefully) gives the caller some more freedom as to what that sequence may look like.

I didn't try to do anything particularly clever in splitting the sequences up, and some cleanup could be sensible at some point. Basically I split the sequences into three parts:

• calibration: any algorithms that can be shared between multiple working points
• working point: any algorithms that do things specific to a a working point that can't be shared between object types
• post processing: any algorithms that can be shared between all object types (essentially container copies and debugging histograms)

There is one algorithm that could go into either the working point or the post-processing, and I chose working point: And that's the algorithm that collects all the decorations for that working point and makes an overall selection decoration for that working point. My reasoning here being that while that is a completely generic algorithm it is still something we will always want to do and that the working point sequence will feel incomplete if we leave it out (unlike the post processing which the user could easily do his own way). If we find that is not the case we could move this around later on (or make it optional).

Also, I found that at least in some places we have two types of selections: One for the analysis object selection and one for the output object selection. For simplicity/consistency I just forced that on all sequences, but it may be worth revisiting at some point.

I also had to do some amount of reordering to fit into this overall scheme. Most notably the e-gamma sequences did one of their WP specific selections before running calibrations. I flipped the order (at least for now), as this is essentially a performance optimization (skipping calibration for some objects) and we can bring it back later if we decide that such an optimization is worth the headache it brings with it.

I also updated the photon sequence no longer to use view-copies internally, but instead rely on preselection decorations. Since that is the way we said all sequences ought to have been working already that seemed like a sensible change.

I also put the preselection configuration into the tau sequences. Technically that is not used, but it allows pre-loading preselection algorithms.

I'm not sure how sensible my updates to the di-tau sequence are, but the original sequence was neither functional nor complete. The unit tests for that sequence were already commented out, and the sequence itself doesn't even contain a selection algorithm. Still I tried my best to update it, to reduce future work.

I did leave the original top-level function around, calling the new functions as they ought to be called. That is mostly meant for backward compatibility and it ought to be fine to call the new functions directly as a user (though they may see more updates to calling conventions than the top-level function).

cc @tadej @jburr @lheinric @vimartin

cc @okiverny @christos (in case they want to comment on the re-orderdering of e-gamma algorithms)