SceneStateManager -> BasicSceneBuilder
Add various object creation methods to BasicScene
Remove redundant threadAllocators parameter from BasicScene::CreateMaterials()

Remove SceneProcessor interface class (only had one implementation)
Rename ParsedScene -> BasicScene

Also, added a small InternedString wrapper to make usage a little clearer.

This saves another ~400MB and 0.5s time to first pixel with the Moana
Island scene.

This saves nearly 3GB of RAM with the Moana Island... (And gives a ~10%
time to first pixel speedup.)

There's no need to carry around a heavy ParameterDictionary here; getting
rid of it markedly improves Moana startup time.

First here is now SceneStateManager, which implements the ParserTarget
interface and takes care of handling graphics state management. As parts
of the scene are defined, it passes them along to a SceneProcessor, a
new interface that currently has a single implementation that now takes the
name "ParsedScene".

In time, this will make it easier to try asynchronous creation of scene objects
as parsing occurs. For now, it seems to give a ~5% reduction in startup time
for the Moana Island scene.

The previous implementation repeatedly assumed that Allocators were
thread safe; this is not required for std::pmr allocators, but happened to
be the case when the default allocator is used on the CPU (since new/delete
are thread safe.) For the GPU, the CUDATrackedMemoryResource was
also thread-safe, but it also included some per-thread caching that doesn't
really belong in a memory resource.

Therefore, the WavefrontPathIntegrator (and friends) now no longer assume
that allocators are thread-safe, but instead explicitly use per-thread allocators
in parallel code. CUDATrackedMemoryResource is simplified to be just a
memory resource, and now we use a std::pmr::monotonic_buffer_resource
when we actually want chunked allocation.

Assorted cleanups; no functional changes.

* Generalize GPU rendering path to run on both CPU and GPU

Now we have a WavefrontIntegrator that can both run on the CPU (backed by
ParallelFor() for parallelization and pbrt's aggregates for ray
intersection acceleration) and on the GPU (backed by GPUParallelFor() for
parallelization and OptiX for ray intersection on NVIDIA GPUs.)

Beyond generalizing the code, this refactor allows CPU-side debugging and
testing of the wavefront integrator.  Doing so allows further isolation of
the GPU-specific code into a few source files, now just ~2.5k lines of code.

This includes a bug fix in the wavefront medium code to resolve MixMaterials
to one of their constituent materials before enqueuing material evaluation
and shading work.

Note that on the CPU, the wavefront integrator runs 5-10x more slowly than
pbrt's regular CPU integrators, so it is not recommended for regular use...
Co-authored-by: NWenzel Jakob <wenzel.jakob@epfl.ch>

With that change, we were no longer creating textures and materials in the
order that they were defined, which broke scenes that used "mix" textures
and materials that depended on referring to earlier instances of them.

Save those 696 bytes!

"Import" is similar to "Include", though proceeds asynchronously in a
separate thread, which allows improved parallelization of scene parsing.

The only functional change is the replacement of ReportValue()
for reporting STAT_INT_DISTRIBUTION values with operator<<.

(They are essentially useless now that texture and media definitions do not obey attribute scope any more.)

No functional changes.

When a texture is first created, we don't know how it will be
used. Therefore, we create both forms of it and then choose the appropriate
one based on what the Material requests. This eliminates a bunch of cases
where we hard-coded creating ones for Reflectance since we didn't know any
better.