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

Issue #124.

Fixes #25

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.

Issue #112.

This fixes some NaN cases where measured metal IORs didn't cover the full
range and were thence sometimes coming out zero when sampled.

This was getting to be a lot of memory with many threads and
unnecessary, since each thread will generally end up allocating less
from its ScratchBuffer the more threads are also working...

Fixes #60.

(This could be handled in simple cases using e.g. the
WindowedPiecewiseConstant2D class, but handling the
general case seems tricky..)

dpdu and dpdv should not be in terms of the texture coordinates
but should be left to be in terms of the patch parameterization.
(Before, we were computing the wrong PDF.)

This helps keep the renderer from getting stuck when the display server
goes away.

In particular, the latter wasn't updated to account for the notion of int
parameters introduced in c84d8a6a, which
broke --upgrade.

R,G,B is now the default.

Finishes #123.

(As yet untested, but it compiles!)

Issue #123.

(More Windows build warning fixes.)

This fixes the Windows release build for killeroos-gold.

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

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