Improve display range setting

For CompositeImages when possible use actual data range info. Otherwise fall
back to our last best estimate.
Remove obsolete overlay code

If we change the way overlay duplication works in the future,
we can resurrect some of this code at that time.
change behavior of DefaultAutoscaleMethod

It has been the case for a while that we would never return a 0 width
interval (i.e. when data min == data max). However the existing code would
fail for some edge cases and give life to annoying display bugs.

Now we've decided that if data min == data max we will return an interval of
[typeMin, typeMax].
Bump to pom-scijava 1.82

Signed-off-by: Jenkins <jenkins@dev.loci.wisc.edu>
Update to the imglib2 2.0.0-beta-17 release

This release features the 'nonlinear-goodies' enhancements, which rework
axes to support linear calibration with offset (i.e., "y = m*x + b"), as
well as other nonlinear calibrations generally (i.e., any "y = f(x)"
function you might care to define in a subclass of Axis).
DefaultImageDisplay: fix method order and headers
AbstractData: add missing javadoc
DefaultDataset: avoid NPE if ImgPlus axes are null
DefaultImageDisplay: remove obsolete code
AbstractData: do not serialize AxisTypes

After a lengthy debugging session (thanks to Johannes Schindelin and
Mark Hiner for assistance!), we determined that the current approach
of duplicating Overlays via serialization + deserialization was causing
the AxisType of each CalibratedAxis to be duplicated as well. This
happens via somewhat mysterious means deep inside ObjectInputStream, in
that no DefaultAxisType constructor (not even the usually-very-useful
unlabeled curly braces constructor block!) is ever invoked when the
object is created via deserialization. This phenomenon made it quite
tricky to determine exactly how these objects were coming into being.

The symptom was that the Crop command resulted in rogue X and Y axes
propagating. Since they did not match the canonical X and Y from which
they were replicated, they became additional axes within the
CombinedCalibratedRealInterval, and thus became extra X and Y sliders in
the cropped image display. But surely there were many other lurking bugs
relating to this aspect of Overlay duplication, too.

The fix (for now) is to avoid serializing or deserializing each AxisType
object itself, but rather simply save its label.

Ultimately may also want to rewrite the overlay duplication code to work
in a more conventional manner (i.e., have each subclass define how it
gets duplicated). This is how each CalibratedAxis gets copied right now:
via a copy() method which each leaf subclass overrides. But at the
moment it is actually rather useful to duplicate overlays this way,
since we want overlay serialization to work anyway.
Eliminate use of deprecated DefaultCalibratedAxis

We now use DefaultLinearAxis instead.
TextEditor: avoid deprecated methods
TextEditor: add missing @Overrides
TextEditor: avoid potential NPE
AbstractData: avoid deprecated calibration method

This is a quick and dirty fix, hence the FIXME. Ultimately we will need
to serialize axes properly, or else nonlinear axes in particular will be
hosed by the serialization operation.
PixelProbe: use new calibrated axis API

This allows the pixel probe to report calibrated values painlessly,
no matter what the calibration function.
TypeChanger: copy axes, not just calibrations

This is particularly important now that axes have become more
sophisticated with the 'nonlinear-goodies' work.
Update ImgLib2 dependency to 2.0.0-beta-18

Among other things, this adds a new ImgPlus constructor that we need in
order to create ImgPlus objects with CalibratedAxis objects. It also
fixes the ImgPlus#copy() method to completely preserve CalibratedAxis
metadata by using CalibratedAxis#copy().
RestructureUtils: improve createNewImgPlus method

This removes uses of the deprecated calibration approach in favor of
cloning the input CalibratedAxis objects properly.

This change also introduces a proper generically typed method for
creating a new ImgPlus from an input ImgPlus template. It retains the
Dataset signature but leans on the new method to do its work.
EditAxes: remove superfluous error message

A null dataset cannot come in via the command framework because by
default, each @Parameter is required=true, so the preprocessing chain
will barf with "A Dataset is required but none exists" or some such
before run() is actually called.

In the case of the command being called via the Java API, it is possible
that run() could be called without setDataset having been called first.
In that case, the dataset could be null. But you will see the problem
very quickly in any case because getAxes() will throw
NullPointerException right away trying to interrogate the dataset.

So I think the log message is not necessary.