I was very unsatisfied with the old tone-mapping approach for a number
of reasons:

1. The requirement for all tone-mapping functions to be pure GLSL was
   very restrictive and made it so we had to start worrying about
   GPU performance.

2. For the more complicated functions, using a LUT is vastly better.
   Using a LUT also opens us up to using more complicated functions
   overall, like piecewise splines, including exact inverses of other
   tone mapping functions, or functions based on dynamic metadata.

3. Having this be an open-ended API in theory allows users to define
   custom tone mapping functions (e.g. perhaps one based on extra frame
   metadata).

4. Extensible enough to support e.g. inverse tone mapping as well.

I will probably still include GLSL fast paths for tone-mapping functions
that are faster to implement in pure GLSL, but for now I plan on
switching entirely to a LUT-based approach.

The major downside of this approach is that it doesn't afford us the
ability to combine this style of tone-mapping with full peak detection,
but I'm unsatisfied with the complexity of peak detection overall so I'm
not sure this is a huge loss in practice.

One way we can salvage the situation is by always using the detected
peak merely to (linearly) adjust the output of the LUT, e.g. something
like `sdr = lut(hdr) / lut(peak)`.

Closes #154