implement asynchronous bulk/control transfers

[StephanvanSchaik]

This PR mostly draws inspiration from: this comment, PR #143, Multi-threaded applications and asynchonrous I/O.

• Implements InnerTransfer and Transfer like in this comment.
• Wraps NonNull<libusb_transfer> and implements Send such it can be sent across threads, since it is effectively guarded by an Arc<Mutex<T>>.
• Uses Rust's ownership model to claim and pin the buffer and return it to the user once the transfer completes, gets cancelled or errors out to avoid unnecessary allocations, i.e. to put the user in control of these allocations. This should allow for zero copy, as far as zero copy is possible with libusb.
• Implements CancellationToken that can be constructed from Transfer, such that the transfer can be cancelled from other tasks.
• Replaces UsbContext::handle_events() with a thread-safe version as implemented by PR First try rusb-async #143 (and as described by the libusb documentation).
• Fix an issue in the original code where handle_events() does not make any progress when the timeout is zero.
• Export LIBUSB_CONTROL_SETUP_SIZE as CONTROL_SETUP_SIZE as users of USB control packets need to allocate buffers with at least CONTROL_SETUP_SIZE bytes to store the control request setup header.
• Implements an example showing how to asynchronously read from a bulk endpoint.

This integrates nicely with tokio, but should be agnostic of the run-time used since it just relies on the std crate for futures, i.e. any asynchronous executor should work.

I have tried this with a device that supports USB control packets and it seems to work nicely. However, I don't have any experience with isochronous packets, so this PR does not implement that part.

[a1ien]

Can we split this in to two PR. I mostly OK with replace handle_events only one thing it's just use loop and break instead while

[StephanvanSchaik]

Can we split this in to two PR. I mostly OK with replace handle_events only one thing it's just use loop and break instead while

Sure, sounds good to me.

[a1ien]

About async. I want made async in separate crate(as in #143). So can you just create PR with separate crate. You can use
version = "0.0.1-alpha-2" and same name name = "rusb-async" in you PR.
This allow test and select best implementation without releasing many rusb version with different async api. Just publishing rusb-async
After we select best implementation I move async code into the rusb

[kevinmehall]

This doesn't belong here.

When the transfer is not ready, it is poll's responsibility to save the waker and arrange for it to be woken when the event loop should poll your future again. You save the waker on the transfer and wake it from libusb's completion callback. But where does libusb check for events and call the completion callback? Yep, that's what libusb_handle_events and variants are for. So you need to call it somewhere other than poll so that libusb can call the callback, callback can wake the waker, and let the executor know that it has to call poll.

You have two options:

1. Require a dedicated background thread that loops calling libusb_handle_events in blocking mode.
2. If you don't want a background thread and don't need Windows support, you can do the complicated dance to get a set of file descriptors from libusb in a thread safe manner, and arrange for tokio/mio to poll them. When that reports a ready fd, then call handle_events in nonblocking mode.