Support user-specified analog and digital waveforms

[Cody-G]

This issue will track progress toward allowing a fully custom set of analog and digital signals to orchestrate a recording with Imagine. Advantages of this approach:

• We won't have to stop and restart the camera between stacks in order to keep z-slices aligned. This alone removes a big bottleneck in the stack acquisition rate (currently we spend up to 100ms on this)
• We can tune the piezo control waveform to for the experiment (especially important for high-speed). The user will be responsible for tuning and choosing the waveform, not Imagine (for now at least) -Complete flexibility in specifying camera, laser, and stimulus pulse behavior (should dual-cameras be synchronized, interleaved? Should the laser be pulsed once per exposure to reduce motion blur? etc...)

To do:

• [x] Currently we record digital signals such as camera exposure on analog input channels. These can more efficiently be recorded as digital signals. When Imagine was first written this wasn't an option because it wasn't possible to synchronize the analog and digital conversion clocks, but now we can. There is an example of how to do this in the NIDAQmx examples folder (installed with NIDAQmx). This has the critical advantage of allowing us to sample analog and input signals at a higher rate (the analog rate limit depends on the cumulative sample rate across channels)
• [x] Given the change above, it makes sense not to record these signals in the ".ai" file anymore. I think it makes sense to just store them in a separate ".di" file. Or if people prefer we could bundle them together in the same file, but then we shouldn't call it ".ai" anymore, and we should store them in a less raw format (JSON?). Each sample will be an 8-bit bool (or a single bit if we want to compress) so the samples won't be aligned with the analog samples if we just store a raw array.
• [x] Currently the input signal channel names are hardcoded. We should allow the user to specify a custom name for each channel. We should do the same for output signals that the user specifies. For examples, a user may want to use 3 different digital output lines for 3 different types of stimuli, and to specify a name for each.
• [x ] It seems that hardware timing will be better than software timing in every case, so when we are confident that this approach works well we can use it as a "backend" even when the user does not specify a waveform, based only on their settings in the GUI.

[Cody-G]

@kdw503, that looks like exciting progress! Is it okay with you if I merge #30 into dev? Then you can try rebasing this work onto that. The rebase could be tricky in some places...if you are unsure about anything in my code feel free to ask.

[kdw503]

Cody, Can I ask what #30? I can not find #30 in the issue list.

[kdw503]

Now I understand. It is a pull request number. Yes, I am okay with the merge. I will rebase on that after merging.

[Cody-G]

The checklist in my first post is still relevant, though I just reworded the last item a little bit. I'm also creating a new issue and checklist that just focuses on the minimum we need in order to merge the "waveform" branch: #36

[Cody-G]

This seems done, woohoo!

[kdw503]

Yeah! you did nice work!