Add some Rust library building infrastructure

[chrysn]

Contribution description

Building on #16274 this adds a single module that can encapsulate arbitrarily many Rust-based modules.

It's heavily WIP, and will be rebased, but the core idea is something that I already want to have discussable:

• For every RIOT build, there should be at most one Rust crate built and statically linked. That allows cargo to manage shared dependencies well, and avoid code like formatting being pulled in twice.
• The module introduced here is intended to serve as that module if there if crates should come in but no application Rust code is used.
• Conceptually, both the RIOT modules and the Rust crates stay separate:
  • Pure-Rust RIOT modules are pseudomodules on the RIOT side and pull in the single module.
  • The module checks the list of enabled modules, and pulls in the relevant crates.

Note that Rust-only modules have little options to be usable, as otherwise they won't be called into:

• They can export XFA sections (like the demo does).
• They can export implementations of otherwise weak symbols.
• They can do what other modules do, and add extern int module_setup(void); to wherever in the init system they need to be called initially. (Personally I'd discourage that in favor of XFA.)

Testing procedure

It's not a full test, but it's a good one:

$ make BOARD=microbit-v2 -C examples/saul all flash term

TBD

It's all a bit rough so far...

but these items are still open:

• Become less hard-coded -- right now adding a module means changing Cargo.toml, src/lib.rs and the Makefiles
• Be available for application Rust code: Application Rust code should easily be able to take over this module's responsibilities.

Issues/PRs references

This is based on #16274, and will be rebased onto that. Only look at the commits not on that other PR, currently it's the last one only.

[edit: testing procedure]

[chrysn]

Rebased to track #16274

[chrysn]

@kaspar030, are you happy with the adjustment?

Rerunning tests given the failed one looks like a glitch (being unrelated and not having failed in other recent runs)

[kaspar030]

ACK.

[kaspar030]

Please squash!

[chrysn]

Thanks! Squashed. In removing the "REMOVE ME" commits, I split one of them (the one that made the rust-gcoap example use other Rust modules) off and kept half of it as the now most recent commit: With how the rust_riotmodules developed since those lines were written, it's now best to just use the riot_rustmodules crate all the time (the usual no-op has no deployment impact), as to tolerate any Rust-written RIOT modules that might be activated as they come in (eg. if saul_default gains support for a board's sensor). While murdock is working this off, I'll run another round of self-review whether everything that's in the commits is still in the righ place, and still makes sense.

[chrysn]

Updated again to fix some commit wordings, and documentation typos or misreferences.

[chrysn]

Builds and tests passed [edit: I hope the link is right -- I lost the original link, reconstructed the URL, and that was the commit that was tested]. I missed squashing after the latest fixup I mentioned in #16833 (comment) (e4279bd). Squashing that in and skipping builds/tests due to the pre- and post-squash having identical tree hashes.

[kaspar030]

Nice!