Update I2C functions to use DMA

[fredyyoussif]

I found this change extremely useful.

@ 100kHz I2C frequency, each run of the update function took approximately 100ms to complete. This put my simple cooperative scheduler out of wack. Moving over to using DMA, this was reduced down to ~10ms, broken into 8 parts, each to trigger the transfer of one RAM page.

This would, of course, be less of an issue if one is using an RTOS with pre-emption/time-slicing, but the load on the CPU would still be unnecessarily high.

Some caveats:

• I have only made this change for the I2C functions, and left the SPI as it is. I see there is an open PR that incorporates DMA into the SPI comms, albeit a different implementation.
• A DMA channel will need to be attached to the I2C peripheral during configuration.
• To avoid the software starting the next page transfer before the DMA completes the current one, I've implemented an interrupt-driven mechanism that triggers the transfer of the next page when the current one completes.
• I have tested this with a STM32C071 only.

[afiskon]

It seems to me that we are in a situation of two competing pull requests. Did you have a look at #93 ? Could you say how your PR is better / different from that one?