Draft: Make the TrackCollectionMerger reentrant.

The TrackCollectionMerger ranks high up in the contention list of the avalanche scheduler. Thus, it may improve the event throughput if the TrackCollectionMerger was reentrant (or if there were multiple clones).

The TrackCollectionMerger does nothing which would disallow running the same instance on multiple events in parallel. In that sense a straight forward transformation into an AthReentrantAlgorithm is fine. It does not cause more problems than the non reentrant version does.

Though, already in its current non-reentrant form it does already something that is not strictly MT safe. Already in its current form it can update the track summery, or event replace the track summary depending on the configuration. The latter could potentially cause problems (no matter whether the algorithm is an AthAlgorithm or AthReentrant algorithm), because other algorithms may access the current TrackSummary at the same time as the TrackCollectionMerger would replace it with a new one. This may lead to the usage of a deleted object. In the current default workflow the TrackCollectionMerger "only" updates some counts in the TrackSummary. Non of these counts are used before the TrackCollectionMerger has processed the event. That is why the TrackCollectionMerger does not cause problems in athenaMT with the current configuration despite being not strictly MT conform. The correct procedure would be to either copy the tracks rather than updating existing tracks which however is very expensive, or to delay the update of the track summary to the track particle creation stage. Then the updated and new information would only be available for track particles which is likely good enough.

Turning the TrackCollectionMerger into a reentrant algorithm may send out the wrong message, since it is not strictly MT conform, independent of being an AthReentrantAlogrithm or just an AthAlgorithm. However, the benefits (reduced contention) may outweigh the possibly misleading messaging.