libbladeRF: Do not crash upon out-of-order transfer completion callbacks

The assert() failures in Windows from issue #351 appear to be the result
of libusb 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.

This has been reproduced on Windows 7 and 8.1 with libusb 1.0.19. The
Cypress backend is not affected.

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.