Logic error would cause the MSP data to be written to every port that had MSP enabled if the selected port was -1 (`SERIAL_PORT_NONE`). Since the (correct) default for `displayport_msp_serial` is -1, this was causing MSP displayPort traffic to be "spammed" to every UART with MSP enabled. Since MSP displayPort is the fallback when no other OSD device is detected (in "AUTO" mode) this could cause large amounts of unnecessary MSP traffic - for example in cases with flight controllers with no MAX7456 and using the DJI air unit connected via MSP. This "might" be related to earlier reports of the DJI OSD no longer working with softserial (even though that's not really a recommended configuration) because of the extra serial traffic.
This was not so much a "bug" but instead a shortsighted design. The only other thing using `mspSerialPush()` is the MSP-based current sensor. In that case the logic does in fact want to "spam" all the MSP ports with the current sensor request. So it was using the `SERIAL_PORT_NONE` identifier to mean "every port". But this conflicts with MSP displayPort logic which really needs a "no ports" identifier. So this PR adds a `SERIAL_PORT_ALL` identifier to explicitly differentiat "all" from "none" and this is used for the current sensor.
Menu including:
- Voltage meter selection
- Current meter selection
- Max cell voltage (moved from MISC menu)
- Voltage scale adjust (moved from MISC menu)
- ADC current scale and offset adjust
- Virtual current scale and offset adjust
How it works:
1. Current Meter Source on FC is set to MSP/OSD Slave by user.
2. On reboot FC sends MSP_ANALOG to OSD Slave.
3. OSD Slave listens for incoming MSP as usual.
4. OSD responds to MSP as usual.
6. The FC recevies the data from the OSD Slave and updates the MSP
Current Meter.
update the MSP configuration of current and voltage sensors to use IDs.
revert the i2s_bst changes, since TBS won't be updating their firmware
there is no point adding new features to it, we just need to keep it
compatible