AP_Scripting: Adds I2C transfer() bindings and an example

[IanBurwell]

Adds LUA bindings for the I2CDevice transfer() function. This is often needed over write_register() as I2C devices might not have 8 bit registers or desire some other custom transfer.

An example script is also added that allows shutdown of a BQ40Z bms chip which would not be possible with LUA without the transfer() function. This script has functionality similar to a sibling PR that implements such functionality more generally in the AP_BattMonitor domain.

[IanBurwell]

Sibling PR: #27288

[IamPete1]

How do you feel about a string vs the tables? The pack and unpack string functions are very powerful for extracting values with the correct format. Its a shame we have the table precedent in the existing read function.

[IanBurwell]

I hadn't considered taking/returning a string which would be more memory efficient, and it would totally be satisfying to be able to do something like

local some_uint32 = string.unpack("<I4", dev:transfer(string.pack("b", 0xAB), 4))

where the string.unpack in handling the byte assembly into a uint32.

But there is also a nice simplicity with using tables. If I wanted just one byte back after a multi byte write it seems like a bit much to do:

local some_byte = string.unpack("b", dev:transfer(string.pack("bbb", 0xAB, 0xCD, 0xEF), 1))

vs

local some_byte = dev:transfer({0xAB, 0xCD, 0xEF}, 1)[1]

But the more I think about this the more a string seems to help even if it incurs a bit more boilerplate. I am going to try and throw together something that uses strings instead.

[IanBurwell]

@IamPete1 I have added an alternative transfer_str binding for comparison and an example that I actually used it to debug with. Do you think we should go with one over the other, or keep both (maybe renaming them slightly)?

[IamPete1]

I have only really reviewed the string version, I don't think we need both, it will just confuse people. Were tending to use strings now for serial and mavlink. I think string is the way to go, but then I have not used either. You have used both, which do you prefer?

[IanBurwell]

Having used them both, I do now prefer the string version even though it brings some extra boilerplate with it. string.unpack is just too powerful.