Re-add Send to async drivers

[bugadani]

In #2980 we changed Async driver to be !Send to prevent sending them to a different CPU. This was done to ensure that the interrupt handlers run on the same core where the drivers do.

This is now being undone for the following reasons:

• It is too restrictive. Besides dedicated GPIOs basically no peripherals require code to run on a specific core.
• RTOS-es, like Ariel OS or even esp-rtos can migrate a thread to a different core, regardless of some drivers on a thread being !Send. This means that we can't make assumptions on which core a particular driver is running, so our solution gave us only a false sense of safety.

This PR adds locks for the stable drivers and accepts that the rest may be silently unsound.

[Dominaezzz]

• RTOS-es, like Ariel OS or even esp-rtos can migrate a thread to a different core, regardless of some drivers on a thread being !Send.

This messy concept here needs to be properly RFCed. Just because an rtos might be doing it doesn't means it's correct or sound.
esp-hal needs some kind of runtime model properly documented before a big change like this is made. Proper definitions of Send/Sync and acceptance that the whole ecosystem that integrates with esp-hal would have to conform to it.

This PR adds locks for the stable drivers and accepts that the rest may be silently unsound.

Why not just keep the unstable ones as !Send to prevent people pulling out their hairs on heisenbugs?

[bugadani]

This messy concept

What's a messy concept to you? RTOS-es? Async drivers? Send?

The current state is unsound. You can run the driver in an interrupt executor that has higher priority than the async interrupt handler anyway, so you have a data race, no matter if the driver is Send or not.

What is considered a thread boundary (which Send allows to cross) is largely undefined, but I believe it is a property of the OS. An OS can reschedule a thread anywhere it wants, at any point it wants, that's a property of symmetrical multiprocessing. If a driver isn't written to handle this, it's unsound.

Why not just keep the unstable ones as !Send to prevent people pulling out their hairs on heisenbugs?

Why should we do shotgun surgery keep an incorrect behaviour?

[Dominaezzz]

What's a messy concept to you?

Moving a thread to another core. The fact that Send/Sync is not well defined. The fact that thread boundaries cannot be reasonable about when writing a driver or library.

What is considered a thread boundary (which Send allows to cross) is largely undefined

Precisely why I'm saying it should be defined for esp-hal.

If a driver isn't written to handle this, it's unsound.

How does a driver know what to handle when the rules aren't specified?

Why should we do shotgun surgery keep an incorrect behaviour?

I thought that's what you're already proposing.

[github-actions]

New commits in main has made this PR unmergable. Please resolve the conflicts.