Add i2c functions

[Farmadupe]

Integrate all of the cgos i2c described in v1.4 of the API reference.

Read and write functions have been tested against an external i2c sensor plugged into DDC bus an SEVAL devboard, with a SA7 SMARC running debian 12 (kernel 6.10.11+bpo-amd64)

Design decisions:

• This implementation is mostly a direct translation of the C API. I considered making the read functions return freshly allocated vectors as this is significantly more ergonomic, but decided against this. I think it should be easy enough for users to write their own wrappers for this.
• Because the Congatec API reference does not specify what happens when an invalid dwUnit is supplied to any functiona call, I am conservatively assuming this causes undefined behaviour in libcgos. I have added protections against this in I2c::new when instantiating an i2c bus object. The alternative would be to mark all i2c-related functions as unsafe.
• The code should be panic-free

(Thanks for the quick response to yesterday's request!)

[schmidma]

Thank you so much for suggesting this addition! 💪

I am currently unable to actually test these additions on a physical device using cgos and i2c, so I'll just review the changes from a coding style perspective. Feel free to reply or discuss on any of my comments and suggestions.

For keeping track of the conversations and todos, I ask you not to resolve the comments yourself, but rather let the original author of the comment resolve the individual open discussions. This make reviewing a lot easier from the reviewers perspective.

[schmidma]

same as below, naming: count vs number vs amount

[schmidma]

What is your opinion on this? Can you comment, why you do not intend to make a change here?

[Farmadupe]

Happy to make changes as requested.

• Feedback is required over amount/count name
• I accidentally closed the query about the libcgos api returning 0 for success. I confirm that the underlying libcgos does return 0 for success.

[Farmadupe]

All changes made.

[schmidma]

Thanks for addressing the changes, a few conversations and requested changes are still open and to be applied or discussed.

[Farmadupe]

Comments addressed. The most recent commit also adds panics in the unlikely event a user passes in buffers whose length cannot be represented by u32. (I thought about adding an error but I decided this situation can be considered to be an implausible programming mistake)

I believe all remaining open comments are those where I currently do not plan to make a change. Please advise if I am expected to press the resolve button in these conversations or how I should initiate further discussion.