Add tracking ported from LCSoft

[jmcarcell]

BEGINRELEASENOTES

• Add ported processors that are used in tracking: ConformalTracking, ClonesAndSplitTracksFinder, RefitFinal and TruthTrackFinder
• Add ported tracking utilities and tools that are needed for the algorithms
• Add tests to run the new Gaudi algorithms and compare their output to the output obtained from the Marlin wrapper
• Add some README files with comments about the stuff that is ported, for example, which parts have not been ported.

ENDRELEASENOTES

This PR reimplements what's needed to run tracking for CLD in Gaudi, without using the Marlin wrapper. The baseline is to have the same output as the CLD tracking.

This PR includes a reimplementation of a few files:

• https://github.com/iLCSoft/ConformalTracking/blob/master/src/ConformalTracking.cc
• https://github.com/iLCSoft/MarlinTrk/blob/master/src/MarlinTrkUtils.cc
• https://github.com/iLCSoft/MarlinTrk/blob/master/src/MarlinDDKalTestTrack.cc
• https://github.com/iLCSoft/MarlinTrk/blob/master/src/MarlinDDKalTest.cc

plus others from ConformalTracking and MarlinTrkProcessors.

There is still a dependency on KalTest and DDKalTest that makes this depend on LCIO.

During porting this, a bug in DD4hep was found. After AIDASoft/DD4hep#1414 is merged, the tracks obtained are exactly the same as the ones obtained with the original conformal tracking (except the time of the track states, that is set to -1 by the converter from LCIO to EDM4hep and here it is not being set, so it's 0).

An additional bug that only affects ClonesAndSplitTracksFinder is described in key4hep/CLDConfig#69 and fixed in iLCSoft/MarlinTrkProcessors#73.

Not all the histograms and plots are being filled, I may add more in this PR or in the future.

[andresailer]

Having the GaudiDDKaltest and related pieces in a separate library would be useful for key4hep/k4GaudiPandora#11 for the DDTrackCreator parts.
https://github.com/key4hep/k4GaudiPandora/blob/bf728c4d3adb9f678f23904c4a0932c390bf356f/k4GaudiPandora/src/DDTrackCreatorBase.cc#L68-L71

[tmadlener]

I have the feeling that this algorithm could be split into several smaller ones that are then bound together with a sequence. That would have the potential of simplifying the configuration. I am aware that we have in principle decided that only EDM4hep goes onto the TES and doing this for this PR is probably too much work, but we have to potentially revisit that decision to avoid such large algorithms. Additionally, breaking this up into a pattern recognition and a subsequent fitting / deduplcation algorithm would also make it possible to use ACTS for the latter for example. That could also be a way of reducing dependencies here.

Having said that, that is probably easier to in follow up work.

[jmcarcell]

If there are no more comments I'll merge this soon as I don't plan on doing more work for this PR. Then it can be used in other places like key4hep/CLDConfig#70, for example.

[andresailer]

Thanks!