Shared fmt crate

[dflemstr]

Extracts all of the copy-pasted fmt modules into a shared crate.

@Dirbaio said this had been tried but wasn't possible. Blame my crazy insomnia but I needed to give this a try to let CI tell me whether I was wrong.

[dflemstr]

Propagating the defmt feature is of course a bit tedious; I did my best to do it consistently in this PR. This is an example of this upstream cargo issue: rust-lang/cargo#9094

I created a tool that might be useful for automating this in the future: https://github.com/dflemstr/cargo-feature-aspect

However, it would require embassy to transition to using a Cargo workspace, and I would say it's outside the scope of this PR to start using a tool like that. I might run it once as a separate PR once this is merged.

[Dirbaio]

I appreciate the enthusiasm, but when I said it doesn't work I really meant it. There's some downsides inherent to having a shared fmt crate:

• The defmt feature gets enabled for the entire embassy-fmt crate at once. This can cause issues like: user depends on crates foo and bar, enables defmt on foo but not bar. foo propagates it to embassy-fmt. this enables it "indirectly" for bar as well, when it does info!("whatever") it'll get printed with defmt even if the defmt feature isn't enabled there. Now, if bar is printing a SomeStruct which has cfg_attr(feature="defmt", derive(defmt::Format)), it'll fail to compile becuase info! will try to print it with defmt but Format is not implemented.
• The fmt crate becomes public API. This means major releases can become breaking. Example: user depends on foo and bar, enables defmt on foo only. This enables it on bar indirectly, which the user might rely on. If we release a new embassy-fmt and a new bar that uses it, the logs for bar will stop working for that user.

this is not an exhaustive list.

Ii'd really prefer to keep fmt.rs as-is.