The Future class is now gone, and its functionality ("is the result
ready?", "give me the result value") is now folded into AsyncJob.  This
allows retrieving the result from multiple threads, with synchronization
handled in AsyncJob.  (This is more flexible than std::future allows, since
we don't need either move semantics or the ability to pass along exceptions
when the future is harvested.)

This fixes a number of race conditions that helgrind was flagging during
startup with complex scenes.  (Our prior use of std::future wasn't correct
in that we had unprotected access attempts from multiple threads.)

This allows users to not need to worry about thread safety in their
callback implementations. In particular, this fixes a race in the
BVHAggregate's use of ThreadLocal that rarely led to crashes or complaints
about malloc heap corruption during BVH construction.

Given C++'s rules for initialization of statics, I don't think this is
strictly necessary, but it makes helgrind happy and causes no harm.

There were two signed integer multiplications that readily overflowed. They
are now both unsigned, which is well-defined under overflow.

Issue #177.

(Rather than just printing a warning.) Issue #152.

Not only could this make the scale go negative for half of the possible
orientations, it could go to NaN as well. Fixes #130.

Fixes #146; thanks to @kanition for noting it.

- Pass along as much metadata as is still valid
- Update pixelBounds when --crop, --repeatpix, or --flipy are used
- Also updated the semantics of --crop's parameters to be w.r.t. the full image resolution

Also, add a color space check to checkImageCompatibility().

This is especially important for keeping track of what RGB color
space images are in...

For 3-channel images, write out the channels, whatever they are.
For 4+, write R, G, B channels only (and error if not present)

If the first PDF was too large, it would become infinity when it was
squared, which in turn would lead to a NaN being returned.

Before, e.g. "float foo" "bar" would not lead to an error being issued.

Instead it's computed as needed. (No performance impact in practice
even though it does introduce some redundant computation.)

And remove last (unused) vestiges of Oren-Nayar...

Issue #196 via @shadeops.

Preemptive attempt to avoid bugs of the sort that were fixed for the wavefront
integrator in 07d4749c.

Now that ScratchBuffer grows on demand, we don't need to be so fancy
about it.

Now Material implementations have a GetBxDF() method rather than GetBSDF()
and they directly return their associated BxDF type, whatever it may be. This
slightly cleans up all of the GetBxDF() method implementations with no real
impact on the code that calls them.

This gives some more headroom in the RGB polynomial which helps if
things are relatively saturated...