Add volume-to-material mapping and change import data

[sethrj]

This adds to the OpticalMaterial a mapping of volume ID to optical material ID; it is allowable to have no ID assigned (so that another part of the code can kill the track etc.) I've also changed the import material data so that the optical material ID is associated with the physical material ID, since it's conceivable we'd want to turn on/off optical physics in different regions of the problem.

A few changes are:

• Instead of looking for scintillation etc. in the first optical material, we look at all materials, since the user might want to turn off processes on a per-material basis
• Any material with an RINDEX property is considered "optical"; the other physics properties are optional.
• I've added an "optical" data selection to the geant importer that defaults to on; we should think about detecting the presence of optical processes to specify whether cerenkov (e.g.) is enabled

Currently

[amandalund]

Looks great, thanks @sethrj!

[stognini]

Just so I am in the same page, let me know if this statement is correct: the plan is to keep the scintillation by particle import code, but we're not implementing that yet in our generator. So we keep per-particle data on the import side (and ScintillationData, though will be empty), but do not enable it in our ScintillationParams, leaving the stepping loop to be material-only. And if/when we do add scintillation by particle type, all the backend and data storage is already in place, since the current extra bits shouldn't make any real difference in the stepping loop.

[sethrj]

Yeah, that's about the sum of it. Since I don't think we've yet found any sincillation-by-particle detector we could probably delete it and restore it later if needed... 🤔