Provide a callback for TX flush, rather than a wait function.

[martinling]

This fixes #1164, but currently causes some erroneous output to be printed in hackrf_transfer e.g:

$ hackrf_transfer -c 0 -n 100000
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(900000000 Hz/900.000 MHz)
samples_to_xfer 100000/0Mio
Stop with Ctrl-C
 0.0 MiB / 0.011 sec =  0.0 MiB/second, average power -nan dBfs

Couldn't transfer any bytes for one second.

[martinling]

The message Couldn't transfer any bytes for one second appears only for -n 393216 and below, which corresponds to three 256KiB transfers.

That seems to be an unrelated issue, related to the way stats were adjusted for the preload bytes in https://github.com/greatscottgadgets/hackrf/commit/8a9af7a1add97f82ed4b62d4d0b84e021e0a0219.

However, we can now Ctrl-C when -H is used with those -n values, which does fix #1164.

[martinling]

Added an additional commit to fix the hackrf_transfer stats.

[martinling]

Added several more commits to solve remaining problems with hackrf_transfer output, including the introduction of an additional callback for the completion of a TX transfer, which greatly simplifies the bookkeeping work needed on the client side.

[martinling]

Added some further commits to ensure that the flush transfer is included in the cancellation and locking arrangements.

The flush callback now takes a success parameter to indicate if flushing was successful or cancelled/failed.

[martinling]

Something about this branch breaks Ctrl-C on macOS. I'm investigating.

[martinling]

Bisection shows the breaking commit is 9f7715e5.

[martinling]

Now fixed; resubmit wasn't being initialised to false outside the if blocks.