AcqOutputHandler: Provide more useful information

Originally output handlers were not informed of the current timepoint/view
index. Ideally they wouldn't need to be, but for some of the more
structured output modes (specifically OME-TIFF), the information is
extremely useful.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
OME-TIFF output handler rework

This particular issue has been rather painful, all things told truly.

I decided to change the way the program outputs OME-TIFFs: now, each
view/timepoint is its own image, matching the filesystem structure. The
upside is they can have varying plane counts, supporting continuous
acquisition. The downside is different time points of the same view aren't
considered related (strictly speaking).

The OME-XML specification isn't totally clear (to me, anyway) on how these
things relate. For instance, the 'plane' elements that reference the
actula 2D image data are assigned time and Z indices that should relate
them to each other. However, since two such elements from different times
are now under separate parent 'image' elements, things like the bioformats
importer don't recognize them as the same.

Unfortunately the two behaviors are mutually exclusive: An image cannot
consider two blocks with varying Z counts to be the same position. In a
future commit I hope to restore the 'correct' behavior but only in the
case of well-structured (constant dimensions) data. And perhaps if it
becomes possible, I can implement the 'correct' behavior for
poorly-structured data by multidimensional padding.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Better integration of continuous acquisition

Previously, continuous acquisition wasn't possible with writing to disk.
This was largely because OME-TIFF can't support ragged/poorly-structured
data, which continuous acquisition rather implies: because thread
scheduling is nondeterministic, image capture rate varies, leading to
differently-sized Z stacks for the same span of Z coordinates.

A previous commit enabled the OME-TIFF handler to output such data (at the
expense of the XML structure not appropriately reflecting the data
itself), so this capability has been restored. With a few other tweaks,
continuous acquisition works with the OME-TIFF handler.

There are still serious drawbacks -- the framerate, for instance, is
apalling. It may be that our motors are too fast (over a 1500-um span, we
get ~50 images). As I mentioned in the OME-TIFF commit message, the data
structure isn't correct (the stacks aren't considered related by the
Bio-Formats Importer). Anti-drift does not work with continuous mode yet.
These issues are to be addressed in future commits.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
WIP: ProgAcq: Implement IAcquisitionEngine2010

One of our goals is tight integration with Micro-Manager's acquisition
engine. Some of our functionality, like continuous drive, can't be
implemented using the provided extensibility. So instead, we'll provide a
different implementation which will be a drop-in replacement for the
Clojure code. This implementation will live in
ProgrammaticAcquisitor.java, which is more or less made for the purpose.

Things to be wary of:
- Needs a custom output handler which drains to a blocking queue.
- Not sure how to supplant original implementation yet.
- Needs to be a strict superset of MM's functionality.
And more.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>