Refactor optical model input

[sethrj]

We're having problems separating out model construction and materials and adding new models because they're all entangled.

Short term

Support empty MFP grids for materials without data (needed for rayleigh):

• PhysicsTrackView::calc_mfp should check grid first, return inf if not present
• Loosen assertions in RayleighModel constructors and build_mfps and elsewhere
• Add a test

Long term

We should move to a model like inp::SurfacePhysics. To inp::OpticalPhysics add:

using OpticalRayleighMaterial = ImportOpticalRayleigh;
using OpticalProperties = ImportOpticalProperty;

struct OpticalRayleighProcess
{
    std::map<OpticalMaterialId, OpticalRayleighMaterial> materials;
};

//! Processes and models for volumetric interactions of photons and material
// (add to inp::OpticalPhysics)
struct OpticalBulkPhysics
{
   OpticalRayleighProcess rayleigh;
   OpticalWlsProcess wls;
   OpticalWlsProcess wls2;
// later, add Mie
};

// Add to inp::OpticalPhysics:

  // Optical properties for each optical material
  std::vector< OpticalProperties > properties;

Steps:

1. Move optical properties from ImportOpticalMaterial to OpticalPhysics and update the rest of the code
2. Add inp::OpticalBulkPhysics to constructor of optical::PhysicsParams and update build_optical_params in celeritas/setup/Problem.cc (eventually get rid of ModelBuilder)
3. Replace Rayleigh model constructor to take inp::OpticalRayleighModel and optical material params; remove from imported.optical_models, update GeantImporter to load data into the new inp and build Rayleigh inside optical::PhysicsParams if any materials are present

[hhollenb]

Related, I'm working on a simple surface physics model that does extremely trivial interactions for optical physics. Adding it to the current optical models requires hard coding it into a few places in the input and model builders, which isn't ideal for something that we'll use for debugging / validation / benchmarking but very rarely for production runs. I think it might be able to serve as a simple case for user-defined models while refactoring inputs?

[sethrj]

@hhollenb I think that's a great idea, and do you think it could wait until we have the basic surface crossing "working" (or at least to a point where it doesn't crash and we can test it?)

[hhollenb]

I think the input side can definitely wait, but we may want to use the models for debugging since they'll be simpler than the dielectric interactor (e.g. a surface only absorbs or only transmits or only reflects)

[sethrj]

Fair enough! I think we could make this work really easily by putting a bool debug_physics{false}; into the surface physics list, which should be excluded with the others, and then just build the models internally to the SurfacePhysics class?