remove SampleBuffer

[sjkelly]

This partially addresses #26 and #24. The idea is to go back to a more generic mechanism, and eliminate some sources of issues:

• on some drivers activate/deactivate` calls do not free memory, we should likely avoid them and always Just Be Fast ( activating/deactivating is an issue on many hardware anyway).
• Fewer abstraction layers, more suitable for potential SampledSignals integration, or other
• we no longer need to carry around the MTU, and we leave it up the the user to optimize for latency if desired.

I believe this is likely a more correct fix to #17 and #12.

TODO:

• test on different hardware
• check flags
• update docs
• will readStreamStatus help?
• what to do about latency measures?

[sjkelly]

This seems to be a minimal fix for the dropped packet issues on the xtrx.

[sjkelly]

check flags

Seems dubious, as we already found out, on most platforms. Checking the nread is most robust.

will readStreamStatus help?

This is not universal unfortunately, and an extension of the flags issues

what to do about latency measures?
We make the mtu of a stream transparent to the user now with <Stream>.mtu. Though as noted in some other comments, MTU is only one of the knobs one can turn for latency/throughput optimization.