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. (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.