Replace custom UsbError::WouldBlock with nb implementation

[DusterTheFirst]

The api of usb-device uses the UsbError::WouldBlock variant to signal that the current operation is waiting on the device. This is great for allowing non-blocking implementations of usb, but can be verbose to handle if the goal is to block on sending this data. The embedded HAL team has developed https://lib.rs/crates/nb which aims to standardize this behavior and comes with nice macros like block!() which simplify working with apis that use nb. The usb-device crate should adopt this standardized method to match what other crates in the embedded space do.

[mvirkkunen]

I don't think nb is that useful in practice because it doesn't allow composition of operations like futures do. If it doesn't even do that, it doesn't justify the extra layer of unwrapping you have to do to get to your data. In the future, when enough things are stable, I do dream about writing an async version of usb-device and then we would have a reasonable way to do blocking-ish operations.

Additionally the way usb-device is currently structured cannot reasonably accommodate blocking operations. Blocking in the nb way while waiting for a class implementation to do something requires holding a reference to it while you're doing it, and the UsbDevice::poll method (which has a somewhat strict timeout for calling it and cannot wait for your long blocking operation to complete) requires a &mut to every class implementation you're using, which cannot co-exist with the reference you're using to block.

[ryan-summers]

Closing this since there's no desire to migrate over. Additionally, nb is largely deprecated nowadays for true async as it is.