Progress on thresholding API, with Brian
Rename AutoThresholdMethod to ComputeThreshold

We want to differentiate between the layer that _computes_ thresholds,
versus the layer that _applies_ them by iterating over an image.
GlobalThresholder: remove misleading comment
ApplyThreshold: add javadoc TODO reminder
GlobalThresholdTest: use clearer test method name
GlobalThresholdTest: use simpler op invocation
GlobalThresholdTest: use clearer output var name
ComputeThreshold: generalize javadoc

It isn't guaranteed that the computation uses a histogram.
Threshold: clarify javadoc

The "threshold" op can be either threshold computation or application.
MapI2I: fix javadoc
Rename Otsu to ComputeOtsuThreshold

This name is clearer about the purpose of that specific class.
AutoThreshold: remove unneeded comment
ComputeOtsuThreshold: add TODO reminder
ComputeOtsuThreshold: tweak comment
ComputeOtsuThreshold: use histogram for the input

It is more modular to allow reuse of a histogram which might already
have been computed at an earlier time.
ApplyThreshold: use Comparable<? super T>

The Comparable interface is not recursive... rather, it should be
allowed to use _any_ Comparable implementation that is as general as,
or more general than, the type T. This approach (Comparable<? super T>)
is the typical pattern in the Java standard library.
WIP: rejigger ApplyThreshold class hierarchy
ComputeThreshold: do not constrain to Comparable

The recursive "T extends Comparable<T>" is likely not correct; usually
with Comparable you do something like "Comparable<? super T>". For now,
let's forget about Comparable till we need it again later.
ComputeOtsuThreshold: extend OutputFunction

For the moment, we put a dummy createOutput implementation; this is no
worse than the previous behavior, since it did not check for null.
GlobalThreshold: tentatively rename