21.9 pixel svc fix

These changes are to fix an issue recently observed for both step 2.2 and step 3.0 layouts where the building of the dynamic service material for the pixels was being skipped because XML files couldn't be found by PathResolver following the removal of all geometry Xml files from the release.

In the new changes, the checking of the presence of the files in the release is removed, and in this case the tools building the dynamic services get correctly triggered, and should be able to retrieve the necessary geometry information either from the DDDB based on the geometry tag, or from ITKLayouts as appropriate.

A few points to note:

• Previously there was a method (error-prone and opaque, in my opinion, since we managed to do it by accident here) to run without pixel dynamic services defined. Now, following the change here we currently need both dynamic and static services defined, which is normally what one would want. If we want to be able to run without dynamic services, we should come up with a new method to control this, not relying (in my view) on the presence or absence of a certain Xml file in the CLOB/ITKLayouts. This could be either a python flag or (better, IMHO) a field in the Xml. Feedback here is very appreciated.

• This also removes a deprecated method for building dynamic services (used only for no-longer-supported LoI-style geometries) from any still-used code (including from some interfaces through which its use was configured via passing a boolean). In a next pass (once we see that this works fine) we can go further and remove also some no-longer-used classes and python configuration.

This has so far been tested just with RunUpgradeTests.py - note that the MR also updates the geo tag used there to allow this to work properly. In this case, I see:

• Numerous output changes (expected, since we change the detector significantly)
• A slight reduction in the memory usage (I think because we no longer try to load the old-style dynamic service building, which was previously done in some places even when not actually used).
• One extra WARNING triggered which is tricky to pin down, since it seems to not actually print anything :-S

What is missing here is a detailed check to see that following these changes we can actually confirm from e.g. a material scan that the services are present and correct. If someone can suggest a simple test recipe to do this, that would be appreciated.

FYI @nreadiof @nova @fcostanz @npetters @goblirsc @lmijovic @cohm