Add fix for color swaps not accessible via dropdown menus.

[ctbrahmstedt]

Aloha!
First off, this project is amazing. I can't believe it's taken me this long to discover it. But, to the point, I have a set of walkway lights that use the SM16825 IC. The manufacturer has a color order of B R CW WW G because they're psychopaths. Because of this, there wasn't a way in the standard dropdown options to fix this - I effectively needed to do two swaps. WW+CW and G+CW. I ended up just downloading the repo and changed the output order to R G CW WW G on the SM16825, and then did the BRG swap on the controller. This kind of worked. It worked in that the colors are mapped like they're supposed to, though I think blue is only outputting 50% of it's max brightness. I also can't use automatic white calculation. I only just downloaded the repo and compiled it for the first time a couple of days ago, so I think it's a color order of operations issue with gamma correction, CCT, etc.

I think instead of a color order dropdown/swap page, the color input should be X dropdown menus for as many colors as the fixture supports, and each dropdown have a R, G, B, WW, CW option. That way, every possible combination is accessible. Another beauty of this approach is that it's expandable for future fixtures that use > 5 LEDs (WW, NW, CW) etc, and you just have to dynamically add dropdowns for each addon.

Perhaps for an "advanced user," the options for each channel could be "White" or "Color," with an option for the user to fill in the actual Kelvin of the white LED, so that the white balance would be consistent across different fixtures, and for colors, either a degree on the hue circle, or the wavelength of the LED. At some point, I'd like to whip up a batch of my own LED PCB's with a wider gamut with dedicated Amber, Cyan, Yellow, and UV LED's. Similar to how white can be calculated from RGB, I could stay in the RGB color space, and automatically calculate A, CY, Y from RGB. To achieve this, I would likely just use two WS2805's on the same board and group them. That part is probably outside the scope of this addition, but a small tweak on how the colors are initially mapped could pave the way for a lot of expandability.

I haven't yet digested the full codebase, but if I can get the above working steady enough, I'd be happy to contribute the changes.

[blazoncek]

Unfortunately there is no consensus between manufacturers regarding color orders with SM16825 chip.
Supporting all of possible orders and swaps is impractical IMO.