[Enhancement] Non-streaming transmit and receive in libhackrf?

Hi!

This issue is mainly testing the waters for interest in an enhancement to add "non-streaming" transmit/receive capability to libhackrf. This would add a hackrf_tx_now/hackrf_rx_now or similar, which takes a fixed-length buffer and enters TX/RX mode only long enough to send/fill (respectively) that buffer. This would support the following use cases:

1. Some applications (such as hackrf_transfer) do not multitask and as such implementing a pair of streaming callbacks is unnecessary control flow. A beginner who only cares about writing one main function in their program can use HackRF synchronously.
2. Integrating HackRF support into a larger, non-thread-safe program (e.g. as a plugin) becomes easier, since the full buffer can be rendered in the plugin code and transmitted at once (synchronously or asynchronously).
3. Most importantly, if these functions can be made to work even while libhackrf is already in streaming mode, they can be used to momentarily switch transceiver modes for half-duplex operation. This allows HackRF users to implement bidirectional protocols that require acknowledgements: the HackRF can remain in receive-streaming mode, and whenever a packet comes in that needs acknowledgement, the non-streaming transmit function is used to send the acknowledgement. The receive stream is padded with zeros for the duration the HackRF is in transmit mode so the receiver doesn't lose timing.

A few considerations:

1. This will most likely need special attention in the firmware. We will need to add a new hackrf_vendor_request at least to support this operation, and perhaps even add a second pair of bulk endpoints to transfer the non-streaming request while the streaming operations continue.
2. The HackRF does not switch TX/RX modes instantly; I seem to recall someone saying it took about 100us. Should the function return timing information about how many streaming samples were dropped to make way for the non-streaming buffer?
3. Should these functions be synchronous? Asynchronous returning a handle that can be checked/waited on? Asynchronous with a completion callback? What arguments should they take?
4. If asynchronous, what should happen if someone calls the function twice in a row (i.e. before the previous operation finishes)?
5. Should these functions support overriding transmit streaming to transmit a different finite buffer, and vice versa for receive?

Most importantly: Is the demand for this worth the change to the fundamental operation of the library/firmware to support cutting in the middle of an existing stream?