feat: add an I2C controller abstraction

[ROMemories]

Description

This PR provides an abstraction layer for I2C support, in controller 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::i2c::I2c, and can thus easily be used by any device driver relying on that trait.

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

Issues/PRs references

Depends on #422

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?

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 I2C.

Future work

• Provide DMA-enabled drivers in a dma module inside i2c::controller.

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.

[ROMemories]

CI lint and cargo-test jobs are currently failing because the i2c modules expect some laze context cfg flags to be set on some architectures, which could be done for clippy with RUSTFLAGS='--cfg context="esp32c6"' for instance.

@kaspar030 Should we try to leverage laze for running clippy or is it fine to pass only the required cfg flags using that environment variable? If the latter, it's not obvious to me that rs-clippy-check allows to do that as easily as passing CLI arguments.

[kaspar030]

CI lint and cargo-test jobs are currently failing because the i2c modules expect some laze context cfg flags to be set on some architectures, which could be done for clippy with RUSTFLAGS='--cfg context="esp32c6"' for instance.

@kaspar030 Should we try to leverage laze for running clippy or is it fine to pass only the required cfg flags using that environment variable? If the latter, it's not obvious to me that rs-clippy-check allows to do that as easily as passing CLI arguments.

Using laze would be ideal but seems like more work. I think we might nudge rs-clippy-check into the right direction by adding a step before each arch-specific clippy call setting RUSTFLAGS, e.g.,

- run: echo "RUSTFLAGS='--cfg context=\"esp32c6\"'" >> $GITHUB_ENV
- name: clippy for ESP32                                                                                                                               
  uses: clechasseur/rs-clippy-check@v3                                                                                                                 
  with:                                                                                                                                                
      args:  ...

Could you try that, also if it works two times in a row (later entry in GITHUB_ENV overrides previous)?

[kaspar030]

LGTM (minor last CI fixes)!

[ROMemories]

Could you try that, also if it works two times in a row (later entry in GITHUB_ENV overrides previous)?

I had to remove one of the quotes; the following works:

- run: echo 'RUSTFLAGS=--cfg context="esp32c6"' >> $GITHUB_ENV

[kaspar030]

LGTM, please squash!