fix(color): Scroll order for 'FlySky' module options

[philmoz]

Fixes #3477

Also fix simulator crash issues related to FlySky module.

[richardclli]

@pfeerick This need to be merge in 2.8.3 as well.

[pfeerick]

LGTM on NV14 and TX16S, squash merge when ready @richardclli (just double check the commit message before merging as GitHub has a habit of not using the PR title).

[richardclli]

The implementation has some problems. Need to figure out how the options sync, there are a few observations in the code:

1. Some options are saved in yml

        emi: 2
        telemetry: 1
        phyMode: 3
        reserved: 0
   

2. These options will be updated when parsing AFHDS3 data in afhds3.cpp

    moduleData->afhds3.emi = cfg.v0.EMIStandard;
    moduleData->afhds3.telemetry = cfg.v0.IsTwoWay;
    moduleData->afhds3.phyMode = cfg.v0.PhyMode;
   

So the problem is:

1. Are these information better not saved to yml? Or the yml need to be updated once these options are read?
2. How can the UI reflect the change of these options?
3. Current the options can only be changed in bind. Can the UI trigger changes and send back to the module on the fly?

I think it is better to work more about this in 2.9 and leave 2.8.3 as is. @pfeerick

[pfeerick]

Sounds good to me, given these are issues outside of the scope of this PR.

I believe some options may needto be saved in yaml, but the rest are sourced from the module since they are determined by which receiver id is active - it's a matter of determining the balance, and making sure they stay in sync. One think to bear in mind is that if all the settings are saved to the yaml, this allows the simulator to better reflect the radio config ;)

For point 3 - you really need to ask Flysky if it is a bind time or runtime option, then we can work forward from that.

[richardclli]

Sounds good to me, given these are issues outside of the scope of this PR.

I believe some options may needto be saved in yaml, but the rest are sourced from the module since they are determined by which receiver id is active - it's a matter of determining the balance, and making sure they stay in sync. One think to bear in mind is that if all the settings are saved to the yaml, this allows the simulator to better reflect the radio config ;)

For point 3 - you really need to ask Flysky if it is a bind time or runtime option, then we can work forward from that.

Point 3, I think it is a runtime options, but I will work with Flysky to ensure the correctness.