WIP: Doubly asynchronous output

Unfortunately, async output is not always enough. In particular, overnight
time-lapses have apparently run into troubles, according to Pete. (And
worse, this was on a 64-bit computer with 24GB RAM.

So I'm changing strategy. Rather than limit the image queue on
construction, I'll monitor the memory available according to IJ and decide
whether to (a) enqueue a full image, (b) write the image to a temporary
file and enqueue that path, or (c) block and wait for enough space to do
(b).

Obviously, (c) is the bad choice. In the past we've avoided that using
only option (a), then falling back to (c) if there's a problem.

Option (b) sounds expensive, but it's actually not too bad -- IJ is very
quick about writing out a TIFF. It's slower than storing in memory, but it
may still buy enough time to keep acquiring images.

In general, these changes should improve the async's ability to cope with
long-term acquisitions. The thresholds are raised (from a hard line of
0.5*available memory, to 0.6*max for straight enqueue and 0.8*max for
ram-disk-ram enqueues), and using the current available memory should
allow GC to help more.

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