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
duplicate 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 code is ever invoked when the object is
created via deserialization. This phenomenon made it very 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.

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.