Rust stable support

[Dirbaio]

This PR adds (limited) stable Rust support!

The drawbacks are:

• No #[embassy::task], #[embassy::main]. (requires type_alias_impl_trait). You have to manually allocate the tasks somewhere they'll live forever. See example
• No async trait impls (requires GATs). Note that the full API surface of HALs is still available through inherent methods: embassy-nrf: migrate to embedded-hal 1.0, embedded-hal-async #552 stm32: expose all functionality as inherent methods. #581
• Some stuff is not constructible in const (requires const_fn_trait_bound), although there's an (ugly) workaround for the generic Mutex.

So it's not that bad in the end, it's fully usable for shipping production-ready firmwares. We'll still recommend nightly as the default, until GATs and type_alias_impl_trait are stable.

[huntc]

I infer that the goal here is to permit new people to get started with Embassy a means to do so without having to pin their toolchains. if that's the case, then perhaps we should make all of the examples avoid nightly features... The examples should always be easy to apply to one's own code. Thoughts

[Dirbaio]

The experience is really bad if you can't use #[embassy::task], #[embassy::main]. Check how ugly is the example.

Not being able to use async traits is really bad, this means you won't be able to use any async hal-independent driver.

I see stable support as the following:

• Have some answer for those people who will not use nightly no matter what, saying it's not "production ready" (an opinion I personally disagree with), but whatever. They can now use embassy, but with huge caveats.
• Ensure we don't depend on more nightly features than strictly necessary, to ease the transition to fully stable when the ones we do need become stable.

[huntc]

Approving given that I now fully understand the motivation.

[Dirbaio]

bors r+

[Dirbaio]

Actually, for blocking HAL use, stable support is quite valuable. embassy-stm32 is already a quite competitive HAL vs the stm32xxx-hals from stm32-rs, due to being 1 unified HAL for all stm32 families (consistent API, already supports more peripherals vs the less maintained ones). So there's that as well :D

[bors]

Build succeeded:

• all