io: add defmt support, release v0.5

[Dirbaio]

following discussions in #450, the Cargo feature is named defmt-03 instead of defmt. This leaves the door open to add support for newer versions of defmt in the future without breaking changes, naming the features defmt-04 or defmt-1, like this:

[dependencies]
defmt-03 = { package = "defmt", version = "0.3", optional = true }
defmt-04 = { package = "defmt", version = "0.4", optional = true }

// needed to prevent defmt macros from breaking, since they emit code that does `defmt::blahblah`.
#[cfg(feature = "defmt-03")]
use defmt_03 as defmt;
#[cfg(feature = "defmt-04")]
use defmt_04 as defmt;

[cfg_attr(any(feature = "defmt-03", feature = "defmt-04"), derive(defmt::Format))]
pub enum Blah { .. }

One downside is this breaks if you enable both defmt-03 and defmt-04. This is annoying, because in theory it should be possible to impl both the 0.3 and 0.4 Format on the same struct. However in practice it's unlikely that a user wants this since defmt doesn't allow mixing major versions in the same binary anyway.

[Dirbaio]

updated most of Embassy here, no issues to report. https://github.com/embassy-rs/embassy/pull/1752

[ryankurte]

One downside is this breaks if you enable both defmt-03 and defmt-04.

because the generated macros refer to defmt by path i don't think this can ever be possible* ? but seems like an okay compromise to me.

* without defmt macros internally using versioned paths, or maybe using some macro trickery to get a $1 from the macro invocation

[Dirbaio]

embedded-io, embedded-io-async, embedded-io-adapters v0.5.0 released :rocket:

also, added HAL team as owners.

@ryankurte: because the generated macros refer to defmt by path i don't think this can ever be possible* ?

yeah, I don't think it's posisble either, without changes to defmt.