Decide what to do with unstable (< 1.0.0) dependencies

[bjoernQ]

See #3055 (comment)

We have various dependencies which are not 1.0.0 and won't get there anytime soon.

e.g.

• rand-core
• embassy-embedded-hal
• embassy-usb-*
• log

(and probably more, maybe more in future)

We definitely can't mark anything exposing these as stable

We could gate all of them just by the unstable feature - or should we be more granularly here (e.g. unstable-rand etc.)

We need to decide this before 1.0

[bugadani]

So, considering what the cargo book says:

• Optional dependencies can be enabled using their names as implicit features.
• If there is a feature that uses dep: to enable a dependency, that dependency will not have an implicit feature.
• I believe this hiding of the implicit feature only applies to dep:

If we enable an optional dependency without explicitly stating it is unstable, that dependency becomes part of the stable API of esp-hal. This means we'll be committed to supporting a particular version of a particular dependency.

Not all of our optional dependencies are relevant for the stable esp-hal. ufmt is/may be implemented on UART, which is intended to become stable, but embassy-usb-* only affects unstable drivers. For unstable-only dependencies, there is not much to discuss at the moment - they can all be gated with unstable.

log is something we need to expose on its own, as it is exclusive with defmt, and probably with other versions of log, too. The polite solution I think would be to expose a log-04 feature. We don't want to get stuck with log 0.4 when 0.5 comes out, and we definitely don't want to update to 0.5 as a breaking change. We probably also don't want to get in a situation where we end up with log (0.4) and log-05 features.

Other dependencies (I think that's just ufmt for now) could follow the same scheme, although they may not be exclusive. We can for example add ufmt that enables ufmt-02 now, but 02 and 03 in the future, etc. We may also hide these behind a single compat feature so that they are available stably, or we can also just enable the dependencies unconditionally.

This is just my €.02, and I probably haven't reached the end of my thought process, but that's enough rambling from me.

[bjoernQ]

In case of rng-core we could also just implement the trait from 0.6 and 0.9 (and hopefully not too much next unstable versions) under the unstable flag. Not good for compile times but otherwise nice at the moment since most crates are still on 0.6 (and it will probably take some time everyone adopted 0.9 - at least we shouldn't just bump rng to 0.9 => #3046 )