WIP: fix MCLinking in TDR branch for LHCb::Tracks

@sponce , @raaij , @sstahl The solution I adopted to restore MCLinking for the LHCb::Tracks -> vector conversion, is to append in the MCSequence an algorithm reading all the tracks in the Track container and make a copy of them in /Copy/Track. This allow to run the PrChecker without any issue. Maybe this can be extended to other algorithm which do not allow to merge TDR to master. @gligorov , you may need this hack to setup a timing & efficiency test for CPU using the exact same software stack. To - do -list

• Make the TrackConverter (move to functional) a 1-to-1 conversion One path In , One path Out (KeyedTrack) chained by the PrTrackAssociator using single containers. The final MCChecking sequence will be Per track type produced, i.e. MCCHeckingVelo, MCCheckingUpstream, MCCheckingForward, where optionally, whether no KeyedContainer is produced, a converter is placed in the sequence.
• Let TrackSys and UpgradeChecking sequence to know where converted Keyed tracks are located and which tracks have to be converted (this depends on the signature of the HLT algorithms, i.e. if they produce LHCb::Tracks or vectorLHCb::Track

Now, you can pass TrackSys().TracksToConvert = ["Velo","Upstream","ForwardFast"] to convert from vector<Track> to LHCb::Tracks when doing MC association. Also TrackSys().VeloUpgradeOnly = True will execute VeloOnly ( and Decoding detectors) in the sequence. The last can be useful concerning @cattanem suggestions in Brunel!344 (closed)