On-demand images, take two

[MV10]

This is sort of a cross-pollination of my previous effort and the existing capture handlers. As mentioned in the issue, it gives us the on-demand single-image capture capability I wanted, it retains the continuous-capture capability of the existing handler, and requires no extra classes or interfaces. It should also perform very marginally better, it shouldn't accidentally store incomplete frames, and the timestamp format is configurable when writing those types of filenames.

IFileStreamCaptureHandler

• Adds the NewFrame method to be invoked when the callback reaches EOS

FastImageOutputCallbackHandler

• At EOS, invokes NewFrame instead of NewFile

ImageStreamCaptureHandler

• Adds optional continuousCapture argument to constructors to pass to the base

FileStreamCaptureHandler

• Derives from MemoryStreamCaptureHandler
• CaptureNextFrame bool property, resets after one write if CaptureNextFrame is false
• ContinuousCapture bool property, when true also keeps CaptureNextFrame true
• FilenameDateTimeFormat string property
• LastWrittenPathname string property
• continuousCapture = true argument to constructors to keep existing behavior
• Use last pathname for GetFilename and GetFilepath
• NewFile writes on demand and only when invoked by NewFrame (which is automatic)
• NewFrame manages the capture properties and resets the MemoryStream
• Private field _skippingFirstPartialFrame bool, true until NewFrame is invoked once

Conceptually, the only big change is that no "ambient" file stream is open, so it doesn't make sense to query for the "current" filename/path. Performance should be identical (or better) since file streams are just memory streams under the hood with some occasional flush behaviors. This also means CurrentFilename is only set when the filepath-based constructor is used.

Logically, NewFrame (invoked at EOS) checks if a capture is requested. If so, NewFile is invoked. If continuous capture is disabled, the capture flag is also disabled. Meanwhile, if NewFile is invoked externally, but next-frame capture is not enabled, the flag is set to true which waits for EOS, then NewFrame invokes NewFile.

Fixes #163

[MV10]

I was just thinking about that comment in your code about not calling File.Exists repeatedly. I think that could be resolved by comparing the new filename to the most-recently-written filename. If they're the same, then you start adding the auto-increment counter. I think that way even very high-speed writes (like 4X binning) would have relatively high throughput. We may not need the other pre-defined filename approach at all (though I can see how it would be desirable for other reasons).