topcat: display progress when drawing as well as reading data

In most cases drawing slow plots will display progress, though
currently not always.
jniast: fix DefaultGrf/Plot to work headless

As spotted by Satoshi Eguchi (NAOJ), the Plot class cannot be used in
a headless environment because it constructs a JFrame instance.
The reason it does this is to be able to supply a suitably initialised
JComponent instance to DefaultGrf as required by the DefaultGrf constructor.

There are various ways around this, but it looks like DefaultGrf
doesn't really need a JComponent in any case, it just wants a
FontRenderContext.  This change gives DefaultGrf a new constructor
that only needs a FontRenderContext, which means that Plot no longer
needs to construct a JFrame.
topcat: refactor progress bar updating

Use new class Progresser, which handles out-of-EDT updating of progress bars.
topcat: log progress for more plot operations

Now identifying a (clicked-on) point and turning blob-selected points into
a subset, which can both be time-consuming, both have their progress
logged with the plot progress bar.

Did a bit of other other refactoring and tidying up at the same time.
topcat: put sketch toggle action in toolbar
topcat: click-to-center now logs progress
topcat: rationalise progress reporting and interrupt checking

Now handle all progress logging and interruption checking when iterating
over TupleSequences within a DataStore wrapper (GuiDataStore).
This makes the code more uniform and less messy, and may deliver some
performance benefits - at least it's possible to tweak any changes in
the iteration loop in one place now.
topcat: add a control to turn on/off progress reporting in plots
ttools: allow plotter to have multiple positions

Replace Plotter's hasPosition method with getPositionCount.
This is effectively a generalisation so that a plotter can
plot tuple sequences which represent zero, one or more positions
in data space, rather than just zero or one.

TuplePlotter, as well as getting some relevant changes, is also
renamed to AbstractPlotter, which is a more appropriate name.

JELDataSpec is refactored slightly so that Coords and associated JEL
expressions are aggregated into a new class CoordValue.  This makes it
tidier anyway, but especially with the way that coordinates are now
processed in Plot2Task.
topcat: refactor SimplePositionCoordPanel

Use composition/wrapping rather than inheritance.
This will make it easier to provide other options, like multi-position
instances.
topcat: allow multi-position coordinate entry panels
ttools: add pair plotter

Pair plotting is now done by a plotter with two positions, rather than
a single-position plotter with two extra non-positional coordinates.
This sidesteps the problem with changing DataGeoms, and generally
makes more sense.

Plotting is currently very basic (the only style option is colour).

Line drawing is done with a LineGlyph class, which is a placeholder
for a better implementation to come; it is currently grossly
inefficient and not thread-safe.
topcat: allow multi-position gang layer controls

If suitable plotters are provided by the plot type, topcat will now
display multi-position gang controls for 1 and 2 position plotters.
So you can now do pair plots.

The provision of non-positional controls is somewhat generalised
as well.
ttools: fix plan bug in LabelPlotter

A plan was being construed as matching even when the value type of the
associated cache map did not match (String instead of DepthString).
Actually, I'm not sure how this could happen, because I thought that
2D plots would always use String and 3D plots would always use DepthString,
but the fix, which involves storing Class<T> in the relevant places and
testing for equality, is harmless in any case.
ttools: replace Pixellator with Pixer in plot2

Pixel iteration is now done with one-use only plot2.Pixer objects
dispensed at iteration time by the Glyph rather than with re-usable
plot.Pixellator objects.

The main reason is to allow thread-safe iteration over pixels during
the plotting.  However, it also opens up the possibility of more
efficient algorithms.  LineGlyph has been rewritten much more efficiently
by using Pixers.

MarkForm and MultiPointForm still use Pixer adapters for existing
Pixellator objects.  This may not be very efficient, and the intention
is to rewrite the corresponding code without any use of the legacy
Pixellator-based code.
ttools: plot 2D pair lines without both ends in bounds

Previously pair links were only drawn if the points at both ends
fell in the plot region.  Now for 2D the line will be drawn anyway,
whether both, either or neither of the end points are in the
plotting region.

It would be nice to get this in 3D as well, but it's harder.  Maybe one day.
ttools: plot 3D pair lines if only one end is in range

Pair lines are now plotted if either end is in the cube, it doesn't
require that both are.  This does mean that you get lines poking
out of the cube sometimes.  It would be better to truncate the lines
as they pass out of the cube faces.  Maybe one day.
ttools: generalise ShapeForm to accommodate multiple positions

The ShapeMode/ShapeForm colouring machinery can now be used for
multi-point shapes such as links between groups of positions.
ttools: replace PairPlotter by PairLinkForm

You can now do pair links with all the usual colouring options.
ttools: generalise position to multi-position plots

A new plot form is added which lets you plot pairs of markers rather than
single points.  To support this, the MarkForm class is generalised to
provide implementations with 1 or more points plotted using the same marker.

Alongside these changes, all access to data positions using DataGeoms
now takes account of the fact that there may be any number
(not just zero or one) positions in a tuple.
This required changes to PointCloud.  The resulting PointCloud/SubCloud
class is working fine, but the interface is a bit messy, and should be
tidied up later.