* 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>

This fixes the debug build on Windows on the GPU. (Release crashes with OptiX complaining about malformed PTX.)

The issue is essentially the same as why *this is copied in GPU lambdas
rather than being passed as a pointer; we are accessing the GPUPathIntegrator
in read-only fashion from the CPU during rendering and with unified
memory on Windows, it isn't allowed to concurrently access it on the GPU.

This also fits with the data point that 82ace326 is when things first started crashing.

Issues #41, #48, #72, #89 , and #96.

This saves launching a separate kernel to do so, which isn't really
necessary and gives a few percent performance benefit on simple scenes.
(There is no meaningful benefit with more complex scenes, but it doesn't
hurt...)

Instead, just push those rays onto the ray queue for the next ray depth.
This gives up to a 5% speed up for scenes with participating media.