rust: Update dependencies, build and test more on stable

[chrysn]

Contribution description

This is a bit more than the usual "bump dependencies", as it also reaps the benefits from the latest crate updates:

• The overrides that say "we take riot-sys and riot-wrappers from git" are commented out. This results in builds (especially those of the imminent release) will thus fetch code from crates.io only, and not resort to direct git fetching. I consider this fitting for a release, see also Rust: describe that crate versions should be bent away from git Release-Specs#251. If updates need to be done during the next release cycle that require quick fixes, the lines can just be enabled again in the same commit that then also does the cargo update that is necessary to apply the updates into the Cargo.lock files anyway.
• Tests can be run on stable.
• Examples are prepared to run on stable (which for native means that the panic=abort setting needs to be added to Cargo.toml, for otherwise nightly-only features would be required)
• The hello-world example is run on stable.
  This could have been done before, but was not, because users often build on a simple example when exploring advanced things, and there might have been frustration when the advanced things don't work there. Given that barely any riot-wrappers features require nightly any more, this is fine now.
• rust-gcoap is prepared to be run on stable. It can't right now, but users who have beta installed can already run it.

Testing procedure

• Green CI (I'm throwing in run-tests too)

Issue references

By running tests on stable this closes #18500

[chrysn]

I've added one more commit that sets -Os and -lto on Rust code, which gets the code size from 87KiB to 57KiB on the rust-gcoap example. This hopefully counteracts other effects I couldn't pinpoint yet that let the binary size grow to the point where it exceeded some boards' capacities.

[edit: Numbers are on microbit-v2. Before this PR, Rust code size was 46KiB, so chances are I'll still need to investigate why things grew that dramatically]

[chrysn]

The size increases is due to coap-message-demo's newly gained CBOR serialization and deserialization default handlers (two new demo resources); the rest of the changes did not significantly impact the sizes. Just flicking on some optimizations allowed leaving the list of supported boards as-is. At some point we'll have to reconsider which examples we can pack in, and/or whether there are demos that are shed under flash pressure, but right now, they still fit.

Unless reviewers disagree, I wouldn't try to remove features from coap-handler-demos (it's not possible right now, but then again I'm maintaining that), and leave the optimization flags in (as they do make a good example case).