Methods with double buffers can incorrectly apply "chip" settings.

[Makuna]

Describe the bug
Some chips have settings that are included in the color data stream. These are set by using the NeoPixelBus::SetPixelSettings().
Some methods use a double buffer, such that after each call to Show(), the buffers are swapped.
If a sketch has a case that uses both of these, and then calls Show(false) to optimize the send to not copy data from one buffer to the other (usually due to the sketch expecting to draw the complete buffer each frame), then the settings are only present in one of the buffers and output will alternate with correct and then incorrect settings.

To Reproduce
Use an ESP32 with RMT method.
Use a LED that contains settings defined by the Feature.
Use a sketch that call Show(false).

Expected behavior
Both buffers should be updated with the settings.

Additional context
Current method architecture has the settings applied by the Feature, which has no insight to the double buffering in the Method. So a work around is that even though Show() is called with false, it should still copy the settings between buffers. But are the settings always at the front of the data stream.
NEXT BIG RELEASE the Methods architecture has already been reworked in a branch that makes this issue non-existent sa the Method stores the settings and applies it rather than the Feature applying it. But this is still months away at best.

[Makuna]

#845

[Makuna]

https://github.com/Makuna/NeoPixelBus/releases/tag/2.8.3