imath removal, removal of non-combined modules (VMR, TE, TC, PR, ME, MP), and new combined TB module

[aryd]

PR description:

This PR has code developed over a long time that includes the removal of the iMath code, removal of the non-combined modules and new TB code that combines TB for multiple seeding combinations. Plus many other cleanups.

PR validation:

This code is running and producing tracks. Need to check that test vectors are OK with HLS.

number of events = 100

efficiency for |eta| < 1.0 = 92.33 +- 0.76
efficiency for 1.0 < |eta| < 1.75 = 93.96 +- 0.93
efficiency for 1.75 < |eta| < 2.40 = 94.51 +- 1.26
combined efficiency for |eta| < 2.40 = 93.14 +- 0.54 = 2076.00/2229.00

efficiency for pt > 2.00 = 93.14 +- 0.54
efficiency for 2.00 < pt < 8.0 = 92.79 +- 0.63
efficiency for pt > 8.0 = 94.18 +- 1.00
efficiency for pt > 40.0 = 85.71 +- 5.91

TP/event (pt > 2.00) = 156.71
TP/event (pt > 3.0) = 52.16
TP/event (pt > 10.0) = 4.63
tracks/event (no pt cut)= 173.70
tracks/event (pt > 2.00) = 162.58
tracks/event (pt > 3.0) = 57.50
tracks/event (pt > 10.0) = 5.93

Percentage fake tracks (pt > 2.00) = 2.20%
Percentage duplicate tracks (pt > 2.00)= 1.63%

z0 resolution = 0.10cm at |eta| = 0.05
z0 resolution = 0.41cm at |eta| = 1.95

[tschuh]

I had a look at the code generating the track and stub streams and it looks like you are messing up the stub channel assignment per seed type. That may lead to stub losses (seed type 3 projects only in 4 layers, stubs send on channel >6 won't be used) and wrong interpretation of stub data (e.g. ps barrel stub data interpreted as ps endcap stub). I would recommend to make the ChannelAssigment class available in TrackFit and to use it to make the correct assignments.

[aryd]

After spending considerable time trying to understand the data organization in the ChannelAssignment, TrackStream, and StubStream classes I convinced myself that there was no problem with how was filling this in FitTrack.cc and Sector.cc. There were two issues; the first was easy, we had change the radial position to be stored in 11 bits using an offset. However, the KF code expects the corrected radial position that uses 12 bits. The issue that I struggled a lot with resolving was that in the L1FPGATrackProducer where the StreamsTrack object is filled it assumed that the tracks were stored in the track collection in order of the seed number. But as we now find tracks using two track builders that finds tracks from different seeds this is no longer the case. I wrote a patch that fixes this. But ultimately I think this should be fixed in some cleaner way.

The CI integration test is successful now - I hope we can merge this soon.