Draft implementation of a CPU vs. GPU workflow and infrastructure for Phase 2 HLT tracking

[VourMa]

This is draft PR, aiming to be submitted only after the new tracking baseline is merged in cms-sw (hence the target branch is newTRKAsPhase2HLTDefault. It is opened just so that I can gather feedback on the new implementation of the CPU vs. GPU validation for Phase 2 HLT tracking that this time is generalized to look at built tracks as well as pixel tracks, and can be extended to look at LST tracks (tracks from the LST seeds used in the new tracking baseline) as well, if we feel this is useful.

More in general, the PR provides a direction on how to implement CPU vs. GPU validations for Phase 2 HLT for different objects: paths like DQM_TRKHeterogeneousValidation can be created for other objects and then added to the "heterogeneous validation" menu, HLT_HeterogeneousValid.

This partly supersedes the HLT part of #215, where some updates to the TrackToTrackComparisonHists producer are needed (especially because this producer has been updated in a recent cms-sw PR).

Example result from the newly introduced workflow:

[slava77]

I'm not sure the path files should clone/define new producer modules or worse yet redefine already existing sequences; perhaps I'm missing some design constraints

[slava77]

I have doubts this file should redefine the reference sequence to be validated. Normally I'd expect the reference should be taken in full from the standard path; perhaps HLTMkFitInputSequence

If the idea is to avoid mis-configurations in the SerialSync mirror, perhaps it's better to define these mirror modules and sequences in the places where the reference is defined (check with Marco if the config parsing/validation tools may introduce constraints)

[VourMa]

Another good point, I will switch to this approach. I avoided it because previously it gave issues with the combinations of procModifiers but it should be OK if run only on the default.

[VourMa]

Superseded by #240