feat: add an SPI main abstraction

[ROMemories]

Description

This PR provides an abstraction layer for SPI support, in main mode.
It focuses on providing non-DMA-enabled drivers, which still provide an async interface, with timeouts—e.g., to avoid indefinitely blocking when the target is not connected.
The drivers implement embedded_hal_async::spi::SpiBus, and can thus easily be used by any device driver relying on that trait.

It provides ways to either select frequencies which all MCUs are expected to support (up to 8 MHz), or to request the highest available frequency within a range, resolved at compile-time using highest_freq_in.

Issues/PRs references

Open Questions

• Should Frequency be renamed to Bitrate?
• Should we attempt to make the test more generic, so it doesn't rely on a specific sensor?
• The SPI frequency, selected either using highest_freq_in or directly using the arch-independent enum, is only precisely respected on a best-effort basis by Embassy: as the SPI frequency is sometimes configured based on an input frequency divided by a prescaler, which only has a limited number of possible values, the exact frequency actually used can be different from the one selected by the user. I suppose it would be useful to document this. As the documentation of the manufacturer-specific crates is not currently rendered (where I think this should be mentioned), I'm opting for documenting this as part of a follow-up PR.

Limitations

DMA-enabled drivers are out-of-scope of this PR as the number of DMA channels is limited on some architectures and non-DMA-enabled drivers are therefore useful when no channels are left. Moreover, setting up DMA incurs some overhead, and is thus not relevant for small operations as it is the case with sensors, which was the initial motivation for adding support for SPI.

Future work

• Provide DMA-enabled drivers in a dma module inside spi::main.

Change checklist

• I have cleaned up my commit history and squashed fixup commits.
• I have followed the Coding Conventions.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.