979: usb: make HALs depend only on embassy-usb-driver. r=Dirbaio a=Dirbaio

Follow up to #972 

bors r+

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

934: (embassy-rp): Add Buffered UART implementation r=MathiasKoch a=MathiasKoch

### Questions & concerns: 
- ~~Would it make sense to add `RxBufferedUart` and `TxBufferedUart`, for cases where you would want to only buffer one way?~~
- ~~Do I need to be monitoring more interrupt flags than `Receive` & `Receive timeout`?~~

This PR adds working `BufferedUart` implementation, along with `RxBufferedUart` and `TxBufferedUart`. The implementation leaves room for improvement with respect to performance, as it still does not utilize DMA nor the internal UART buffers.

Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

Rename from {Rx,Tx}BufferedUart to BufferedUart{Rx,Tx} to be compliant with stm32 and nrf implementations

973: Rework STM32 BufferedUart internals so we can split into Rx and Tx like embassy-nrf r=lulf a=guillaume-michel

Context:
On STM32, BufferedUart is not splittable into Rx and Tx part like the non buffered version. On embassy-nrf, a RefCell is used to make BufferedUarte splittable.

Description:
This PR add the possibility to split BufferedUart into Rx and Tx without adding breaking changes.

Hope somebody find it useful

Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>

976: rp: enable time-driver in Cargo.toml instead of ci.sh r=Dirbaio a=Dirbaio

bors r+

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

977: Use firmware writer in stm32{f7, h7} example app r=lulf a=lulf

The new FirmwareWriter is useful in particular for these architectures due to the large erase sector size.

Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>

The new FirmwareWriter is useful in particular for these architectures
due to the large erase sector size.

Add BufferedUart implementation, and feature-guard time-driver initialization, to free up TIMER peripheral if not used with embassy executor

975: rp: Disable intrinsics by default. r=Dirbaio a=Dirbaio

bors r+

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

972: Restructure USB crates r=Dirbaio a=Dirbaio

- Split driver from `embassy-usb` to a separate crate. This allows making breaking changes to `embassy-usb` without having to bump all the crates with driver impls, such as HALs.
- Merge classes into `embassy-usb`. Now that breaking changes to `embassy-usb` aren't that bad, having everything in a single crate is much easier.

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

965: (embassy-rp): add RP2040 ROM functions and intrinsics aliases r=Dirbaio a=MathiasKoch

Add RP2040 ROM functions described in section **2.8.3.1. Bootrom Functions** of https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf



Make all ROM functions (normal and floating point) provide both a direct
call that does the operation and a module with a ptr() function to get
the function pointer.

Add a feature to enable automatic caching of the result of ROM table
function lookups.

Add a check for a V2 bootrom when using floating point functions that
require it.  Panic when it's not present.

Add a standardized macro for intrinsics export and connect the simple
ROM functions to intrinsics.

Direct copy from `rp-hal`! Full credit to those guys for all the heavy lifting.

Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

960: Add non blocking Bxcan constructor r=Dirbaio a=andyblarblar

This PR adds a non-blocking constructor to the Bxcan Can wrapper struct. This allows for the creation of the Can periferal without blocking for a sync with the Can bus.

Co-authored-by: Andrew Ealovega <Andrew@Ealovega.dev>

971: (embassy-boot): add blocking API to FirmwareUpdater r=lulf a=MathiasKoch

Also add a split `prepare_update` + `write_firmware` API, to allow for an optimized update API at the exchange of added complexity. 
The old API is left in place to allow users to choose the complexity level that fits their needs. 

Co-authored-by: Mathias <mk@blackbird.online>

969: usb: fix compile errors with the log feature r=Dirbaio a=newAM



Co-authored-by: Alex Martens <alex@thinglab.org>

961: Parameterize Signal with RawMutex r=ivmarkov a=ivmarkov

The `RawMutex` parameter is deliberately chosen to be the second one, so as it can take as a default `CriticalSectionRawMutex`. This way backwards compatibility is preserved, and users utilizing the `critical-section` crate everywhere can just continue to use the more ergonomic single-generic-parameter version of Signal.

I'm thinking we should probably do the same for `Channel`, and move the `RawMutex` parameter as the last one in the list, with a `CriticalSectionRawMutex` being its default. But that's a backwards-incompatible change of course.

Co-authored-by: ivmarkov <ivan.markov@gmail.com>