MS track building - Revise hit sorting & memory management

• The MuonGarbageContainer is an ominpresent monstrum passed around the MS track reconstruction. However, this will be problematic in events with large activity. For instance, I've observed events in the cosmic reconstuction where the garbage container took hours to manage the memory. Solution -> Shovel IT

• The sorting in the MuPatHitTool is kind of peculiar. Measurements are equipped with track parameters which are then used to determine whether hit A is in front of hit B using the direction. The story becomes even more funny, when hits from 2 segments are merged to form a new track. The track parameters of segment A are extrapolated to the ones of segment B. That's launching cannon balls on rabbits. The sorting has been reworked using the radial and longitudinal distances of the associated detector elements in the barrel.

• MuPatHitTool: in very rare occasions, duplicated hits were found arising from the merging of two segments / MS tracks. Inserted mechanism to protect against those

• MuPatHit, MuPatTrack and MuPatSegment have for debugging purposes global reference counters. They're implemented in a generic way in the Trk::ObjectCounter. Remove the corresponding code in these classes and let them inhert from the central ObjectCounter.

Physics impact has been evaluated on a 50k di muon sample in the pt range 500-1500 GeV:

Second check performed on 50k event in the range 10-100 GeV:

Hence, all changes are found to be statistical fluctuations. Full set of checks is given in HighPtChecks.pdf and StandardRangeChecks.pdf

This is a preparatory MR for !58709 (merged)