Modifications to DSTWriters needed for the "Stripping of Turbo" see JIRA WGP-6

During the development of the WG productions for the "Stripping of the stripping", described in https://its.cern.ch/jira/projects/WGP/issues/WGP-6, it was observed that the MicroDST files produced when running on Turbo do not support Momentum Scaling. The root of the problem is in the TES locations of the ProtoParticles. Suppose you are reconstructing the decay psi(2S) -> J/psi pi pi, with the J/psi taken from Turbo and the pions from the "PersistReco" part. The ProtoParticles and the tracks of the pions and of the muons are stored in different TES locations, and therefore they are not found by the recalibration algorithms. While the bug could be fixed a posteriori, i.e. modifying the MomentumScaling algorithm, it should be noted that as long as at least one track is present in the TES that MomentumScaling explores, NO ERROR IS TRIGGERED. This means that the current configuration, possibly with MomentumScaling fixes, is prone to bugs in other algorithms expecting tracks and ProtoParticles of a single decay chain to be contained in a single TES. The bug fix is structured in three steps:

1. Replace the Particle of the particles firing HLT2 (the muons in the example above) with the corresponding candidates stored by PersistReco (this is achieved with a dedicated DV algorithm released in Erasmus. See Erasmus!34 (closed)).
2. Create a MicroDST cloner to move the data objects to a user-defined TES locations (beyond the limitation of prefix+currentTES)
3. Allow MicroDST writer to remap the TES locations of the ProtoParticles from PersistReco to the TES locations where they are expected for Stripped MDST.

Point 2 and Point 3 are addressed in this MR. 2. MicroDST/MicroDSTAlgorithm includes a MoveDataObject "cloner" that unregisters the object from a TES and register it again in another. The existing algorithm has been updated to allow arbitrary output location, which means introducing checks against occupied output TES. In case of occupied TES, I tried to merge the two, but this is only effective if the objects in the two TES were created together and then split for some reason. This condition is not met for Turbo/PersistReco in which the keys of the Gaudi data objects are defined independently and may present overlaps (e.g. one can have a track with key 1 in Turbo, and the same or another track with key 1 reconstructed in turbo). To overcome this problem the "replace" trick at point 1, of the list above, has been implemented.

3. An entry in the StreamConf object defined in DSTWriter has been included in order to allow defining a a remapping between the TES locations in the DaVinci job (output of SelectionSequences) and the TES locations desired for the output MDST. The backend is MoveDataObject described above. In order to move a data object around it is necessary that no sub-object is linked to TES locations with the same root. You cannot move object /Event/TES/location if /Event/TES/location/another/object is present. If you remove or replace the sub-object, you end up with an empty TES location that still prevents you from copying the object in the root (/Event/TES/location/another may be empty once you move /Event/TES/location/another/object, but it still prevents you from moving /Event/TES/location to another TES). For this, remapping a TES location to "None" is interpreted as node killing. (Empty) nodes can be killed to make objects in the root to be moved.

See Erasmus/WGProductions package to see examples of configurations for these algorithms.

Note on backward compatibility. I have done my best to preserve backward compatiblity, introducing optional flags and options to steer the behaviour of the existing objects away from the previous one. Unfortunately, I have found no other application of MoveDataObject to perform actual backward compatibility tests, but I see no way they could fail... DSTWriter has been checked with previous versions of WGProduction suite and is confirmed to be bw compatible.

Target branch. I need this patch to run in WG Productionson DIRAC, therefore a new version of DaVinci, and a new version of Erasmus based on it, is necessary. It would be nice if the modification could be included in the next DV release.