Fix mspSerialPush() selected serial port logic

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.

src/main/sensors/current.c

@@ -279,7 +279,7 @@ void currentMeterMSPRefresh(timeUs_t currentTimeUs)
     if (cmp32(currentTimeUs, streamRequestAt) > 0) {
         streamRequestAt = currentTimeUs + ((1000 * 1000) / 10); // 10hz
 
-        mspSerialPush(SERIAL_PORT_NONE, MSP_ANALOG, NULL, 0, MSP_DIRECTION_REQUEST);
+        mspSerialPush(SERIAL_PORT_ALL, MSP_ANALOG, NULL, 0, MSP_DIRECTION_REQUEST);
     }
 }