Relates to issue #100, #96, #89, and #48...

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

- Minor changes to how hash values are computed for scrambling in the
ZSobolSampler.
- Folded util/bits.h into util/math.h.

Issue #105.

Apparently Manjaro Linux ships with an unrelated /usr/bin/bin2c.

Issue #105.

When building checkcuda nvcc might not be on the $PATH so instead rely on CMAKE_CUDA_COMPILER.

Set PBRT_DEBUG_BUILD via generator expression.

Use -march=native with CUDA builds again using a generator expression that
adds '-Xcompiler' for CUDA targets.  (Hopefully works around #87.)
This gives about a 10% perf. benefit with CPU rendering.

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

* try 2

* ubuntu20.04

* fix

* fix

* fix

* fix

* fix

* fix

* rgb2spec speedup

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

* fix

(Related, issues #96, #89, #61, #48, and #41.)

Superceded by support for exporting to pbrt-v4 in assimp.

This isn't supported in 3.14.3, at least, but list INSERT with a 0 index is
equivalent and is available there.

(PR #73 followup)

Also added a bunch more point sets and input formats.
The radially averaged power spectrum is also output now.

Small utility for computing power spectra of pbrt's point sets.

Issue #87.

This allows customising which warnings are used in which scenarios, like
MSVC warning flags should only be used when compiling using MSVC.

If one of the headers included by optix.cu used PBRT_FLOAT_AS_DOUBLE,
there would have been a mismatch between optix.cu which would never have
it set, and the rest of the code base seeing it defined if the user
enabled that option.

Fixes #69 ("Invalid PTX input on RTX 2080 Ti on Windows")

Using a library avoids modifying the flags for everyone, and they can be
customised using generator expressions like to restrict them to certain
compilers or languages.

Having the embedding depend on the library used for compiling the CUDA
code down to PTX should be enough: according to CMake's documentation

> Additionally, if the target is an executable or library, a file-level
> dependency is created to cause the custom command to re-run whenever
> the target is recompiled.

However this was not happening, maybe due to it being an OBJECT library?
Or maybe some weird behaviour due to the modification timestamp on the
generated PTX file not being updated as the file gets re-generated.

This reverts commit 95b4c9b4.

Issue #37.

CUDA integration in Visual Studio seems broken as even if "Use Host
Preprocessor Definitions" is checked, the host preprocessor definitions
are still not used when compiling device code.

To work around that, define the macros using --define-macro to avoid
CMake identifying those as macros and using the proper (but broken) way
of specifying them.

Attempt to workaround gcc bug.

Issue #37.

In turn, this makes it possible to use -march=native, which gives about a 10% speedup on the CPU...

Issue #47.

Since we have a CMake target, we can do scoped include directories.
Remove duplicate compile flags, and also add compile definitions which
enables PBRT to compile on Windows for Pascal-architecture cards.

Compared to commit a685e020, this also

* changes the dependency to be directly on the library rather than some
  of its object file;
* adds a missing dependency on several generated header files;
* avoids passing `/D _CRT_SECURE_NO_WARNINGS` to nvcc;
* removes compiler flags that are part of the regular CUDA flags.

This reverts commit a685e020, which seems
to have caused issue #56 (the Ubuntu part at least.)

Require SM 5.3 and up (half floats...)
Print a more useful error when the GPU's shader model is insufficient.