Ensure WaitUntilDone is called before OnCompleted

[glopesdev]

This allows chaining of observable sequences to be done with guarantees that the previous action has been fully completed.

Fixes #27

[glopesdev]

@RoboDoig @bruno-f-cruz one outstanding question I have here is whether we want to call WaitUntilDone when a FiniteSamples task is cancelled. Historically I placed it on Dispose so that this call would be done on both completion and cancellation.

In this PR, we are changing the timing so WaitUntilDone is called before the OnCompleted notification, which is vital to avoid triggering other actions in a chain before a waveform or pulse has fully ended. Now I am rethinking what should cancellation mean for these operators. Overall the recommendation of Rx is to bail-out as soon as possible on cancellation, and avoid any active wait periods inside Dispose, so the best might be to cancel without waiting for the finite pulse to finish.

This would effectively allow cancellation of long stimulus trains using TakeUntil semantics, which is not possible now since currently once a finite samples waveform has started you cannot interrupt it. This is a breaking change in behavior though, and I'm not sure how much existing workflows are relying on this.

One important thing to consider is that interrupting a pulse may leave the voltage level at some undefined value (since technically stopping the task can happen at any sample). This may have been part of the original reason why I left the call on cancellation too, but still this has been a common complaint with the DAQmx package, even for the case with continuous samples.

Perhaps we could address this here by allowing the possibility to specify a value to be used as the reset point for cancellation (if not specified, the voltage would be left where it is) as first suggested in #2.

[RoboDoig]

I think either way there are potential headaches with cancellation behaviour. Allowing early cancellation of a task can lead to voltages being left high as you say, but always waiting until the task is done can also leave you in a situtation where e.g. you accidentally write a voltage high for longer than intended and you can't reset until the task finishes.

Is there a possible alternative where we can define an optional cancellation behaviour? E.g. a digital output can either wait until done on cancellation or alternatively write a one-shot default value across all lines on cancellation.

[glopesdev]

Is there a possible alternative where we can define an optional cancellation behaviour? E.g. a digital output can either wait until done on cancellation or alternatively write a one-shot default value across all lines on cancellation.

This is what I was proposing here: WaitUntilDone would be called on completion, and not on cancellation, so if you want to wait just don't cancel the subscription, whereas if you want to immediately bail out you can use TakeUntil.

Also the reset value would be optional, so you could leave the voltage level on cancellation (this could be important for example in cases where voltage level controls position of a motor, in which case aborting might mean "leave motor at current position").