libbladeRF: Handle out-of-order transfer completion callbacks

The assert() failures in Windows from issue #351 appear to be the result of
transfer completion callbacks arriving out of order. This seems to happen pretty
reliably after an event that momentarily spikes CPU load when using higher
sample rates. (Windows 7 and 8.1 with libusb 1.0.19)

When we expect that transfer number N to be available next, I'm seeing that
transfer [ (N+1) % num_transfers ] is actually coming back as the next available
transfer.

For example we get transfers ... 6, 7, 8, 10, 9, 11, 12 ...

This patch is a band-aid to allow us to just use the next available transfer,
instead of assuming which transfer it will be.

While this should keep things running instead of grinding to a halt [1], it does
*not* address the underlying issue. Out-of-order transfer completion indicates
users may get buffers out of order, which is unacceptable. As such, we will need
to keep digging further, and I will register a new issue regarding libusb giving
us out-of-order transfer callbacks.

[1] Arguably, a transient bad buffer is better than an entire application
    crashing, now that we're aware of this.