Don't require Sync for UsbBus.

[Dirbaio]

Currently UsbBus requires Sync and has &self receiver for all methods. This forces implementations to use global critical sections such as cortex_m::interrupt::free. This is a problem for a few reasons:

• Useless overhead if the user doesn't use interrupts (polls in a loop from main).
• Worse interrupt latency in realtime-critical applications.

This PR fixes this by changing all the UsbBus methods to require &mut self, and passing exclusive borrows to the Bus around to all the places that need it.

Disadvantages::

• The API is less ergonomic, the user has to pass the bus to everything, which may mean handling mutexing themselves.

Advantages:

• Possibility to use mutexes other than global critical sections, that have less impact on interrupt latency (RTIC resources, Embassy's PeripheralMutex...)
• No mutexing at all needed if poll-looping from main.
• Simplified UsbBus impls. here is an example of an updated nrf-usbd impl. No more mutexes and cells.
• Faster. nrf-usbd read is 10% faster with -Os, 3% faster with -O3:

nosync -Os:
    test bench_bulk_write ... ok  16 transfers of 65536 bytes in 1.933s -> 4.340Mbit/s
    test bench_bulk_read ... ok  16 transfers of 65536 bytes in 1.582s -> 5.304Mbit/s
nosync -O3:
    test bench_bulk_write ... ok  16 transfers of 65536 bytes in 1.906s -> 4.401Mbit/s
    test bench_bulk_read ... ok  16 transfers of 65536 bytes in 1.498s -> 5.601Mbit/s

master -Os:
    test bench_bulk_write ... ok  16 transfers of 65536 bytes in 1.929s -> 4.349Mbit/s
    test bench_bulk_read ... ok  16 transfers of 65536 bytes in 1.744s -> 4.811Mbit/s
master -O3:
    test bench_bulk_write ... ok  16 transfers of 65536 bytes in 1.846s -> 4.434Mbit/s
    test bench_bulk_read ... ok  16 transfers of 65536 bytes in 1.552s -> 5.406Mbit/s

[Dirbaio]

There was some discussion about this on the Matrix chat

TLDR is: the register layout of many USB peripherals allows concurrently reading/writing to different endpoints (it is the case on nRF, STM32 USBD and OTG), so it's nice to keep that so that different classes can concurrently read/write to different endpoints without locking.

The problem is the current trait still allows things like concurrently writing to the same endpoint twice, which it shouldn't.

I now think some solution like the one in the WIP branch endpoint-trait is better https://github.com/rust-embedded-community/usb-device/blob/endpoint-trait/src/usbcore.rs . Each endpoint is a separate struct, requires &mut self to read/write, but is Send, so you can read/write to different endpoints concurrently.

embassy-usb does it this way, the result is the whole USB stack (core+classes) is fully lock-free which makes it much faster.

I'm not going to keep working on this personally though, as embassy-usb fits my needs.

[stappersg]

Trivial update for the sole propuse that #89 gets an merge request is closed notification.