feat(color): customizable switch UI support

[3djc]

Add custom switch UI support to main branch.

Hardware support was already introduced as part of adc refactor

[pfeerick]

I have no problem with fd52437 being reverted... while it does reduce the amount of repetition, I think it starts to blur the lines between driver and UI/helper code too much... It seems like instead of via includable headers for files like led_driver, some function protos are declared in board.cpp as needed? Some protos are in the wrong place though... as getFSLogicalState getFSPhysicalState , getFSPreviousPhysicalState and evalFunctionSwitches are all defined in switches.cpp, but not declared in switches.h

[3djc]

Not sure I'm following your comment @pfeerick . Seems to me it is now, thanks to Philmoz changes, quite nice

[pfeerick]

Not sure I'm following your comment

Why were getFSPhysicalState , getFSPreviousPhysicalState and evalFunctionSwitches declared in board.h instead of switches.h?

I can see why

void fsLedOff(uint8_t);
void fsLedOn(uint8_t);

were since there is no other header defining them.

[3djc]

History (or copy/paste of history). i think having those under switches.h like Phil changed is much better, but I think we all violently agree :D

[pfeerick]

Like I changed, actually 😆 Ok, good, just wanted to make sure I wasn't missing something. Think I will need to move fsLedOn / fsLedOff / getFSLedState back into board.h as they actually come out of led_driver.cpp, but the rest can stay where they are.

[3djc]

My appologies ! No no makes a lot more sense this way.

[pfeerick]

Nice! :)

[3djc]

This PR is now obsolete given some of the changes that have happened. I think I'll probably do very soon a t15 pr for 2.11 that will include an updated version of this

[pfeerick]

May also need some changes as 40fd258 may not actually work once the T15 is added to the mix... it seems the build will still break either with that radio, or once DEBUG build is added to the mix.