hal: add optional defmt support.

[Dirbaio]

No description provided.

[burrbull]

Defmt is known by its unstability. Is it good idea to depends on it?

[ryankurte]

Defmt is known by its unstability. Is it good idea to depends on it?

fair point, i think it is still useful to have / we'll just have to keep it up to date

[eldruin]

How about naming the feature defmt-0-3 to make the stability status of the defmt dependency clear as well as to potentially support other versions like in nb?
It should be noted that this would be the only < 1.0 dependency embedded-hal-bus would have once embedded-hal 1.0 is out.

[jannic]

Related issue: #460

Making the enums (optionally) derive defmt::Format would be useful for crates using those enums in their structs.
(e.g. rp-rs/rp-hal#654 (comment)). But I agree we have to be cautious regarding the stability of defmt.

[Dirbaio]

• Changed PR to add defmt support everywhere, not just -bus. (adds derive(defmt::Format) to all enums and structs in embedded-hal{,-async,-bus}.
• Changed feature name to defmt-03
• Added some CI fixes
  • We weren't actually testing all feature combinations because include makes no sense.
  • remove testing for thumbv6, leave only thumbv7. We don't have any hardware-dependent stuff, this reduces job spam a bit.

[ryankurte]

the expected amount of cursed i think but lgtm!

(if we do end up with more defmt versions / features maybe we can split the selection and enabling flags but it's pretty moot for now)