Add CMake flags gating Tracking and DCHdigi

[madbaron]

This PR enables the compilation of the package in the muon collider software stack (which doesn't ship Marlin/LCIO, and has an older Delphes version) in preparation for the migration of the charge trasport digitisers discussed in MuonColliderSoft/MuonCVXDDigitiser#17.

BEGINRELEASENOTES

• Add K4RECTRACKER_TRACKING CMake flag (default=ON) gating the compilation of the FCCee tracking
• Add K4RECTRACKER_DCH_DIGITISERS CMake flag (default=ON) gating the compilation of the DCH digitisers

ENDRELEASENOTES

The dependencies Tracking on MarlinUtil can actually be cleaned up by using the pandora helix class and a few more things could be streamlined. I'd be happy to take care of these in follow-up PRs if a more general cleanup is desirable!

[tmadlener]

Stating the obvious first: This will need propagation to the spack and/or lcgcmake packages.

For me nothing speaks against this. I suppose the other option would be to split off the digitisers into a separate repository or package where we have none of these dependencies. We discussed this a while back in a key4hep meeting (notes) and there we concluded to have the tracking related digitizers here. If it simplifies the dependency management I would be open for re-opening that discussion, regardless of what we do with this PR.

[madbaron]

I do think that having digitisers in a place and pattern recognition/tracking software in another would be tidier, especially as k4ActsTracking already sits in its own package, but we can take baby steps on the way there.

I'll be happy to take care of the spack updates as soon as this lands. I don't know where lcgcmake lives :D