This adds a TrackingGeometry Conditions Algorithm which can be used IN ADDITION to the TrackingGeometrySvc. It also contains a "Test Algorithm" which actually just shows how to access the new TG but doesn't do anything with it. It serves as an example how to migrate all clients of the TrackingGeometry to the conditions algorithm. Not all TG Builders (Muon, Calo) are constructed with conditions data, and therefore don't have an IOVRange. I didn't change how they are built.
If you want to look at the changes of copied files, it is easier to look at the files without the cond postfix here: rlangenb/athena!2 (diffs)
As some interfaces changed, I copied the classes used to build the TG into new files adding "Cond" to their names as postfix. These files should be a temporary addition, until everything is migrated from the TrackingGeometrySvc to the TrackingGeometryCondAlg.
I made some interfaces const and didn't copy the file where I thought it wouldn't do damage, the CI will tell me if I forgot to adapt an implementation.
The input file used in the test alg configuration has multiple IOVs but I'm not sure if the TG actually changes. The TG is invalidated on IOV change though and rebuilt. This particular test file is both on cvmfs and on my public afs, loading the file from afs was ~30min (!) faster than from cvmfs.
Changes for https://its.cern.ch/jira/browse/ATLASRECTS-4732