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

Implementations now just return their respective iterator type directly.

A Medium::SampleRay() method implementation handles the general case,
allocating memory with a ScratchBuffer and returning a RayMajorantIterator.

Continued refactoring of Medium implementations, including the addition of a
MajorantGrid class.

Also updated a few error messages related to RGBGridMedium parameter parsing.