Issue #170.

This gets rid of a bunch of unnecessarily duplicated code...
(And removes a long-obsolete assumption that all area lights are
DiffuseAreaLights.)

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.

Fixes #150.

(Which seems to be a strange MSVC + CUDA 11.1 interaction...)

Also, add a check that issues an error if there is a MixMaterial that uses
a complex texture to select between the materials (which isn't supported in
the current implementation).

This way, we can not increment the ray depth when it passes through a
surface that markes the boundary between different media, matching the
behavior of the regular CPU path.

In particular, this fixes some undesirable noise in the wavefront
integrator (and different behavior from the regular CPU path) that was due
to the ray depth being incorrectly tracked in scenes with participating
media and then Russian roulette inadvertently being applied after the very
first surface intersection.

In turn, this gives us valid dzdx and dzdy values with GBuffer film.

Now a MultiWorkQueue templated on the phase function type is used for
enqueuing work items for sampling direct/indirect lighting in media.  With
Henyey-Greenstein as the only phase function currently available, this
reduces to the previous behavior, but it makes it easier to add new phase
functions in the future.

Also piped through time in a few places it was missing in the
medium-related work queues.

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>

Alpha textures now act on emission the same way they do for visibility:
alpha masked regions of the surface do not emit illumination.

Area lights with a constant alpha of zero are (begrudgingly) special cased
so that it is still possible to specify an invisible area light source.  A
hack in DiffuseAreaLight causes those to be sampled with light sampling
only for direct lighting in integrators so that now they are rendered
correctly. (Before, they would be MIS weighted accounting for the chance of
a BSDF-sampled ray intersecting them even though it was impossible for BSDF
sampled rays to do so...)

Thus, "interface" is purely for specifying medium transitions.

Issue #112.

This fixes the Windows release build for killeroos-gold.

(Most other scenes still crash with Windows+GPU, however.)

Issues #48, #72, #89, #96, #100.

(This basically reverts eb353742.)

While this leads to an increase in color noise for scenes with dispersion,
it simplifies all of the integrators (and, for the book's pedagogical
purposes, lets us hold off on discussing this division until a better spot
in the book.)

This is @pierremoreau's suggested fix for issue #100.

I can confirm everything still works on Linux with this fix, but have not
checked the Windows+GPU build.

(Only makes sure everything compiles; doesn't run tests.)