AP_Scripting: Added VSPeak Modell flow meter driver

[Georacer]

This PR as support for the VSPeak Modell flow meter, in the form of a Lua script.

Hardware

The manufacturer has sent me a sensor with developmental software, able to speak a plain binary packet that the script can easily receive and interpret.
It is unknown to me currently if this software is already in general production or only our partner who asked for it has the correct binary. FWIW The manufacturer does advertise compatibility with ArduPilot, thanks to this here script.

Implementation

I have used a scripting battery backend sensor to fill in only the battery current and potentially the current consumed.
I make the convention that "current" stands of liters of fuel per hour.

See the attached instructions.

Known issues

I have employed a hack in the parser to get out of a buggy situation.
Upon boot, the sensor reports 254,0,0,0,0,0,254: Start byte, zero data, checksum.
But if the data aligns wrong in the buffer, it gets the following content: 254, 254, 0, 0, 0, 0, 0, which is also a valid packet, but means that there's 15.xx lt/hr flow.

I couldn't find another solution for now but reject two consecutive 254 bytes.

In general I'd like to find a better, more generic way of parsing serial binary data of a fixed frame size.

[tridge]

I would have preferred this as a battery backend as we only have 1 EFI, so this driver can't be combined with a real EFI engine, which I suspect users will want to do

[peterbarker]

Commit list needs cleaning up! Should just be a single commit - same name as this PR title.

[Georacer]

Almost a year later, I've done some more testing on this, thanks to our partner.

I've tested myself via remote connection the following aspects:
-VSPF_ENABLE=1

• VSPF_MODE=1: The remaining % battery gets reset.
• VSPF_PORT=1: Was set to the 2rd serial.
• VSPF_CFACT=1: No correction.
• VSPF_BAT_IDX=3: Act as the 3rd battery.

I could see the reported current rise and fall as the fuel pump would go and stop. The remaining % would also decline.

@peterbarker the commits have been squashed.

@tridge I don't remember this being an EFI backend, but it is a battery backend now...

Actually the partner asked if this could be an EFI backend, while allegedly he was instantiating another EFI backend for a Swiwin turbine.
By looking at the code, am I correct in seeing that:

• We don't support multiple EFI backends.
• The Lua binding efi:get_backend(idx) is actually bogus: Only idx=0 will return the current backend.
• The ecu_index we are populating in the logs and telemetry refers to what the DroneCAN and MAVLink EFI devices self-publish.

[Georacer]

The description has also been updated.