Add "region" support

[sethrj]

Geant4 regions have custom:

• Production cuts [see G4ProductionCutsTable::CreateCoupleTables]
• Generic "user region information"
• User limits (step limiter, tracking cuts) [see G4LogicalVolume::GetUserLimits]
• Fast simulation managers [see G4FastSimulationManagerProcess::PostStepGetPhysicalInteractionLength]
• Field managers [see G4PropagatorInField::FindAndSetFieldManager]

But many of those can be overridden on a per-LV basis. Eventually we might want to map each combination of these from logical volumes to independent Celeritas regions.

Regions are used in Geant4 for:

• Region-dependent field (disable field outside of trackers), #538
• Region-dependent field parameters (sharing a single propagation kernel): see #883 for description of CMS using it
• Fast simulation, for which we need "onloading" (https://github.com/celeritas-project/celeritas/issues/1894)
• Physics parameters

Execution plan

One PR for each major bullet point

• [ ] Add Regions to inp::Model (this will look a lot like #1955)
  • [ ] New struct Region with label and set<VolumeId> to which it applies. (Most attributes should be part of another class, and keying on region ID, rather than the Region having a bunch of different specifications.)
  • [ ] Load region data in GeantGeoParams: geant_to_id/id_to_geant for G4Region* (add vector<G4Region const*> to GeantGeoParams)
  • [ ] Add tests: add regions to multi-level.gdml, four-levels, lar-sphere, test by extending GenericGeoModelInp and the IsRefEq
• [ ] Integrate regions into runtime code (I'm not 100% sure the best way to structurally do this, but perhaps:)
  • [ ] Rename GeoMaterial* to VolumeExtras* (non-structural data about volumes)
  • [ ] Pass inp::Regions during construction?

Future work:

• Are regions in Geant4 fundamentally about geometry model structure, physics, or both? (From what I can see, it seems more like physics.)
• Should Celeritas try to keep the same regions as Geant4, or should we merge other physics treatments (like field definitions/parameters) into our "region"?
• If we want a broader region definition compared to Geant4, should we have GeoRegionId map to G4Region* and have a PhysRegionId that corresponds to different fields etc.?
• Unless we have a separate GeoRegionId, should we move the region properties to the "physics" input and/or the future GeantPhysicsParams (#1975)?

[sethrj]

@whokion @mrguilima As we discussed last week, please elaborate on the requirements for the region calculations. In particular, I'd like to know in the following geometry: if both A and B are defined as different regions, do the properties in C change based on the full navigation "path", or is it assigned only one region, or is it invalid?

graph TD
    world[world]
    A[A]
    B[B]
    C[C]

    world --> A
    world --> B
    A --> C
    B --> C

https://geant4.web.cern.ch/documentation/pipelines/master/bfad_html/ForApplicationDevelopers/Detector/Geometry/geomLogical.html#geom-logvol-subreg

[whokion]

In Geant4, a logical volume cannot be shared by more than one region, regardless of whether it is a root volume or not. In the example above, the region pointer of volume C becomes ambiguous. While such a situation is unlikely in a real experimental setup, it still breaks the design since logical volumes and regions maintain mutual pointers when geometry is imported from Geant4. @mrguilima is investigating this issue in more detail and will provide a summary of his findings later.