Merge `optical_materials.xml` into `materials.xml`

[wdconinc]

Is your feature request related to a problem? Please describe. There are currently two sets of material definitions, which will lead to overlapping entries (e.g. PbWO4 is moving in that direction with multiple definitions shared between optical and non-optical).

• materials.xml is a definition file for materials using the GDML schema.
• optical_materials.xml uses the lccdd schema.

There is no fundamental reasons to have two files, other than (possibly) readability due to optical property matrices (a possible split which does not lead to duplication could therefore be to keep those optical properties in a separate file).

Furthermore, optical_materials.xml contains more than materials, i.e. it contains optical surfaces.

Describe the solution you'd like

• A single material_properties.xml file with tables of materials.
• A single materials.xml file with all material definitions, which includes elements.xml and material_properties.xml.

Optical surface properties may need to move to dedicated subsystem files where they can be maintained, or need to be made generic. E.g. MirrorSurface_DRICH could be renamed Anomet_Miro_Silver or whatever will be used.

Describe alternatives you've considered Maintain the status quo...

Additional context This could be combined with #47.

[wdconinc]

@c-dilks Mostly affects your materials.

[c-dilks]

Couple of thoughts:

• Could we have surface_properties.xml alongside of material_properties.xml, for the opticalsurfaces? At least the dRICH surface tables may grow in size soon...
• If we end up increasing the number of XML files, we could put them all in their own subdirectory, compact/materials
• The only materials/surfaces with detector-specific names are the DIRC, MRICH, DRICH, and PFRICH.. instead of detector-specific files, we could have compact/materials/cherenkov.xml for all of these; other similar subsystems could be grouped the same way. This would be useful if, for example, all of the RICHes want to use the same aerogel. On the other hand, more files means more places to look for things
• Switching our detector-specific names to be for more common use is nice, but it can make it a bit less convenient to find which materials are relevant for a specific detector; also having detector-specific names may help prevent someone from changing a table without knowing it has consequences for other subsystem(s)

[wdconinc]

• surface_properties.xml sounds like a good idea.
• materials/ directory sounds like a good idea.