WIP: ACTSFW-104 Introduce python based geometry tests

This adds tooling to execute our extrapolation examples and uses RegExes to parse the geometry construction details from it's stdout. This output is then compared against a reference stored in acceptance_tests/ref/*json. This can serve as a regression test, if, for example, the geometry has a different binning than before, this will show up.

In addition, I implemented a relatively dumb parser for the DD4hep XML format in python, which allows me to derive "expected" values for dimensions, binnings, number of layers etc. directly from the input file. These results can then be checked for in the aforementioned geometry building output. A failure here indicates a change in one of the geometry creation algorithms.

I introduced a CI job which uses the build output and runs pytest, which in turn executes:

• the generic detector example
• the DD4hep setups: TestTracker1, TestTracker2 and IBLSimple
• the FCChhBaseline If any of these produces either regressions or doesn't match whats expected based on the XML, the job fails.

If the geometry building output changes, the RegExes might have to be adjusted accordingly. The parsing should be robust enough to ignore any changes to other output.

I hope that this gives us (more precisely: me) more confidence when making changes that can have effects in edge cases that have not been anticipated, and thus are not covered in the other (unit) tests. I think the variety of setups now included in these tests should cover a lot of edge cases.

Before this can get merged, ACTS MR !369 needs to be merged into core.

Thoughts?

Detectors/DD4hepDetector/compact/CLIC/Simple_CLIC.xml

@@ -17,8 +17,8 @@
     </info>
  
     <includes>
-        <gdmlFile  ref="elements.xml"/>
-        <gdmlFile  ref="materials.xml"/>
+        <gdmlFile  ref="../elements.xml"/>
+        <gdmlFile  ref="../materials.xml"/>
     </includes>
  
     <define>