AP_Scripting: Support UART drivers

[WickedShell]

This was something I said I'd take on awhile ago, and then didn't get to for a bit. This allows a script to access a UART driver and read/write from it. There are some future enhancements to make this be more then just a byte by byte read/write, but the basic functionality does work. uint32_t's are also less frustrating to use in scripts now, more details below.

To do this the generator has gained the new concept of an ap_object. This is just a name I've assigned to a userdata which ArduPilot actually manages the memory for. (Userdatas are typically garbage collected by Lua, in this case all we are doing is storing a pointer back to the actual object which already exsists in ArduPilot. Normally you would use a light userdata for this, but I wanted to have a metatable which required the full userdata). ap_objects support pretty much everything a normal userdata/singleton supports, except they can not be a nil punned argument anywhere.

Another change included with this is that the uint32_t as arguments was frustrating me as overly strict. For example the call of begin on a serial port requires a uint32_t to indicate the baud rate. The way master current works is you actually have to do:

port:begin(uint32_t(115200))

This is primarily frustrating as it is basically just a cast hint, but being a dynamic language you tend to forget about the casting until you need it, at which point the program then stops. This is also unfortunate as it serves to allocate a new object that we then promptly use once and forget about, which increases memory pressure. I've changed the generator so that anywhere we want a uint32_t as an argument we will automatically cast it into a uint32_t without any allocations. This is a small quality of life improvement, but should make the boxed numerics a lot less frustrating to deal with. I haven't gone back and tested any of the other scripts, but it is on my to do list.

Finally it's probably fairly obvious but I added a new serial protocol of 28 for scripting use of a serial port.

This was tested using a green cube, on Telem 2 with both a FTDI cable and a loopback cable plugged in.

[SergeyBokhantsev]

Just thought with this user could send small commands to a VideoTX (SmartAudio protocol) to change power for example, or channel.
Or to start/stop recording on RunCam cameras.
Maintaining such scripts will be much more easy task than a complete protocol implementation in the core code.

[WickedShell]

@SergeyBokhantsev I admit I haven't looked at the implementation, but I know RunCam support/control just came into master :)

[SergeyBokhantsev]

@WickedShell yes, I saw that. Support was added into ArduPilot after 2 or 3 years RunCam firstly introduced it. Moreover, there are different versions of the protocol and my old Split camera works with another one.
Of course the implementation in core code provides more possibilities, but implementing any protocol in core code requires much more work. But I believe most people just need to start/stop recording by a RC switch - only need to send a couple of bytes into UART for that)) With scripting anyone could do that in a hour.
Don't stick with RunCam, this is just an use case example. There are another devices exists with own commands.

Another one idea, that also seems like hard to implement naively within core code. I have a camera (RunCam protocol) and a VideoTX (SmartAudio protocol). Even if ArduPilot will have native support of both protocols, I still need two separate UART ports for my two devices. With custom script I may use single UART to control both devices.

[WickedShell]

Valgrind has no complaints with this, just waiting for CI to pass.

@SergeyBokhantsev I wasn't trying to discourage you from any of those ideas. Those are all valid ideas, I was just pointing out that some support was coming either way.