Idea to support more segments and simplify applying an effect to multiple segments

[b3nj1]

Is your feature request related to a problem? Please describe.

Problems:

1. On one of my light setups, I need more than 16 segments, but memory is tight and doesn't allow for this many. Eg, 20 columns where each column is split across 2 segments. The segments can wrap using "mirror", so the I can get by with 21 segments to give the effect of 40.
2. Typically, I only apply 2 unique effects across these many segments. Eg, the top of all columns get one effect, and the bottom of the columns get the other.
3. Changing effects with 16 (or more) segments is tedious due to the need to toggle the select on all the segments.

Describe the solution you'd like

Split the segment struct into 2 different structs:

1. Physical segment

// 8 bytes (fully packed)
      uint16_t start;
      uint16_t stop; 
      uint8_t style; // NEW "pointer" to style/effect
      uint8_t grouping, spacing;
      uint8_t options; //bit pattern for the physical attributes like mirror, reverse, ...

2. Style/effect (needs a catchy name) setting

// 20 bytes (2bytes padding; could be packed down to 16 bytes with some effort by exploiting unused bytes in colors)
      uint8_t options; //bit pattern for the style attributes like selected, transition, ...
      uint8_t speed;
      uint8_t intensity;
      uint8_t palette;
      uint8_t mode;
      uint8_t opacity;
      uint32_t colors[3];

Of course, this would touch a lot of code, but I think in a fairly straightforward way. Configurations migration would likely have some corner cases (eg, if old config had more unique styles utilized on its segments).

At 16 original segments, 384 bytes are required.
With the proposed split, 6 styles and 32 segments would use 374 bytes. If one needed every segment to have a unique style, we could either:

1. use the proposed structs always and reduce the max segments to 13 from 16. This regression is probably unacceptable.
2. fall back to a single struct and support 16. This would make the code ugly to support both modes, but existing configurations would be 100% compatible.
3. repack the style/effect struct so it fits in 16B by reclaiming the 3 unused bytes in the color array. This would allow for 16 segments and 16 styles to fit in 384B. Configurations would 100% compatible if this setting was applied. I think this would be the best option.

Describe alternatives you've considered
To get more segments, I looked into packing data into the unused upper byte of colors, but that's only 3 bytes. 4 bytes need to be found to realize any savings. Even if it could be squeezed out, this would only amount to a 20% increase in number of segments vs the doubling proposed. Also, this would not help with the 3rd point of having to select so many segments.

Additional context

I'm willing to create a PR for this, but I'd like to be sure that think it worthwhile and @Aircoookie is interested in merging it.

Thanks for having a look at this!
Benjamin