Standardize nomenclature

[sethrj]

Singular/plural names for variables/accessors

Add to the documentation (after assuming the team agrees):

• Scalar member variables get variable names of the singular item (material, physics, geometry)
• Vector/collection/array-like variables get plural names (reals, materials, processes)

This means a couple of changes:

• Accessors to SPMaterialParams should be material() not materials even though those classes store vectors
• A single FooState object should be state even though it represents a vector of states.
• In a few places at least, I gave singular names to the Collection storage back ends (see https://github.com/celeritas-project/celeritas/pull/718#discussion_r1165426355 ).

Weird cases to consider:

• Scalar integers like num_streams, max_tracks?
• Params?

Single-item data retrieval

• get() and unchecked_get() for OpaqueID, PDGNumber (get is like std:: smart pointers)
• value() for Quantity, InitializedValue
• obj for JsonPimpl, ReprImpl

Let's make OpaqueId look like std::optional: value for checked access, operator* for unchecked. Same for Quantity and Initialized_value. I think obj is fine for JSON because it's a json object.

Note that some C++ facade classes have base() indicating the single value that the class wraps, so maybe that's a better word too.

ID-based accessors

• get() for KernelRegistry, MemRegistry etc.
• id_to_label and get for views with MaterialParams etc.
• action and num_actions for ActionRegistry

should probably be at() and size() like std containers? But some of these store multiple types (and maybe they shouldn't?)

Environment variables

• ENABLE|DISABLE (see https://github.com/celeritas-project/celeritas/issues/1010)
• CELER_MEMPOOL_RELEASE_THRESHOLD -> DEVICE_
• CUDA_ -> DEVICE_ where appropriate
• CELER_DISABLE_PARALLEL -> CELER_MPI

Class names

• BIHBuilder → BihBuilder etc. (same with several classes in celeritas/em/xs)
• Vecgeom → VecGeom

Other stuff

• TEST_IF_CELERITAS_USE_ROOT vs TEST_IF_CELERITAS_GEANT
• typenames of the form Foo_t vs Foo_type vs FooT?
• allow_redirect, allow_signals to enable_X
• "propagator" advances one step per call (since this is the same as a 'step' in the overall transport), "field driver" performs one trial substep per call, "stepper" performs one integration per call
• traits class names: is_opaque_id vs IsOpaqueId; is_opaque_id_v for value? see discussion
• make all class names LikeThisForConsistency, e.g. numeric_limits
• instead of FooScalars, use FooConstants since some of the "scalars" can actually be fixed-size vectors (? but the point is that these helper classes are fixed size, not dynamic at runtime)
• "Isotopes" should actually be "Nuclides" (see https://github.com/celeritas-project/celeritas/pull/831#issuecomment-2291216735 )
• ExplicitActionInterface -> StepActionInterface

[sethrj]

Also I regret insisting on using Vecgeom instead of following their styling as VecGeom.