Add strobe overlay to RGB LEDs

[mmosca]

This is a change to enable than adding a Strobe blink as a new overlay, similar to #8531

ledConfig_t had no bits free to add new overlays, requiring it to be changed packed struct. which ends up being 40bits (as compared to the current 32).

This change introduces a new 'E' overlay for strob'E' which can be enabled as follows from the cli.

You have 2 leds in your chain, you can use the following command to set them as navigation + strobe lights:

# Led 0, Color + Strobe, Color 5 (green)
led 0 0,0::CE:5
# Led 1, Color + Strobe, Color 2 (red)
led 1 0,1::CE:2

New MSP commands have been added to GET/SET leds and the old MSP command is still supported, but won't allow you to set the strobe mode.

A corresponding pull request for the configurator has also been added that uses the new MSP commands and allows setting the strobe overlay from the usual led UI.

[mmosca]

A quick video showing blink and strobe running side by side

[MrD-RC]

I think that this is the better way of doing it. Changing a LED mode that people already use to blink differently is not the way to go. It should be a new mode, as in this PR. This will also need changes to MSP elsewhere. The Configurator definitely.

@stronnag Anything else that my need attention?

[stronnag]

We try to maintain the MSP public API (as we have no idea who might be using it). Albeit, in this case, I doubt we have many other consumers beyond the configurator.

Historically, We've used one of two approaches:

• Differentiate by length. This doesn't work here as there is both a getter and setter
• Introduce a new (MSPv2) EX(tended) definition and support both old & new (e.g.: new API:
  • MSP2_LED_STRIP_CONFIG_EX
  • MSP2_SET_LED_STRIP_CONFIG_EX

We can always deprecate the old API and remove it in a future release.

Changing a public API without prior deprecation notice is a bit rude.

As the configurator only supports the latest firmware release, it only needs to support the new API.

[mmosca]

@stronnag Is there a rule on how to pick the id for the new _EX commands? Would 248 and 249 be ok? They appear unused.

I will keep the old ones working and they will just convert to/from the new struct and drop the strobe property in the process.

Also, Should I bump the minor API version, since we are adding 2 new functions?

[mmosca]

I can confirm the the legacy commands work. The 6.0.0-FP2 configurator can successfully read/write LED configuration.

[mmosca]

Configurator changes have been submitted in iNavFlight/inav-configurator#1647 and sucessfully tested locally.