Run 1/2 code cleanup in Rec master: Rec/Rec

cc @cattanem @rmatev @sstahl @graven

GlobalReco has a lot of Run 1/2 specific stuff regarding Prs/Spd. If it starts with “Future” it is Upgrade, if it doesn’t and has a corresponding “Future” algorithm (same name) it is Run 1/2. AddVeloInfo is Run 1/2 specific because it adds dE/dX (the upgrade VELO uses a binary redout) although it is in fact still used by the upgrade CALO algorithms. @cmarinbe @jmarchan thoughts on this? The rest is a priori usable in both contexts although some of it like ChargedProtoParticle{Moni,TupleAlg} would need a major rewrite for the upgrade. The scripts in root are in the same category, logically necessary for the upgrade but in need of major rewrites.

ChargedProtoANNPID is relevant to the upgrade. Whether it should continue to live in Rec long-term is another discussion but can be left for later (IMO things like this belong in Phys more than in Rec). @jonrob any thoughts? Depending on this we may want to revisit RecInterfaces also.

LoKiTrack{_v2} are relevant for the upgrade although of course all this will need cleaning up once the event model is agreed.

LumiAlgs will be needed in some form for the Upgrade.

RecAlgs is used in Brunel tests. From what I can see ProcStatAbortMoni, RecInit, RecProcessingTimeMoni, RecSummaryAlg were called in upgrade tests, though perhaps this changed in the recent migration/rewriting of tests? TimingTuple looks like a convenience tool for testing, I don’t actually see it used anywhere in Brunel, it would need rewriting for the upgrade but no fundamental reason why something like that shouldn’t exist for upgrade data.