Bump heapless to 0.9.x and embedded-io-async to 0.7.x

[brainstorm]

This version bump is part of a bigger multi-crate version bump to be able to have new Arc primitives from heapless...

The embedded-io-async bump will also help with other conflicts with other crates that still rely on embedded-io 0.6.x series conflicting with 0.7.x on other crates.

/cc @Autofix

[mkj]

I think the problem is that stdasync Cargo.toml still has the old versions. Make embedded-io-async and heapless workspace dependencies (using the new versions) in the toplevel Cargo.toml then reference those.

The way I exposed modes: Vec in public API in channel::Pty isn't ideal. I guess sunset crate should have a public reexport of heapless so programs can match the crate version. Maybe the same also for embedded_io_async too.
https://lurklurk.org/effective-rust/re-export.html

I guess it won't be such a problem once heapless and embedded-io-async reach 1.0

[mkj]

I think adding unstable-core-error feature for snafu should sort out the Error problem.

[brainstorm]

I think adding unstable-core-error feature for snafu should sort out the Error problem.

Thanks Matt! Seems that the stable channel is now complaining though:

   Compiling snafu v0.8.9
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/snafu-0.8.9/src/lib.rs:5:46
  |
5 | #![cfg_attr(feature = "unstable-core-error", feature(error_in_core))]
  |                                              ^^^^^^^^^^^^^^^^^^^^^^

   Compiling x25519-dalek v2.0.1
For more information about this error, try `rustc --explain E0554`.
error: could not compile `snafu` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Error: Process completed with exit code 101.
0s

Should I add conditional cfg/code to avoid that one?

[mkj]

Should I add conditional cfg/code to avoid that one?

Ah, actually looks like rust_1_81 feature is the one to use instead.

[mkj]

If you want to avoid the slow github actions turnaround time the testing/ci.sh script works fine locally to test stable.

[brainstorm]

If you want to avoid the slow github actions turnaround time the testing/ci.sh script works fine locally to test stable.

Oh, my apologies for the CI/commit noise, I'll try that script out (and embassy's custom build system too btw).