Full blazoncek fork merge

[Aircoookie]

Introduces all features and fixes of @blazoncek dev branch. PR for feedback and adjustments.

[blazoncek]

@Aircoookie any progress on this?

A few main points to test:

• auto-white global override/per pin setting
• settings PIN code/protection
• slider control (effect defaults, slider visibility & name, palette hiding & defaults)
• ESP8266 web stress test
• HA integration (CCT & sensor info)
• UI across different devices (I only have Apple, FF & Safari)

Also, it may be good to add Play and Pause glyphs to Wicons font.

[Aircoookie]

Thank you for the latest additions! :) I have to be honest that I will likely not find the time/energy to get to this in the next 14 days. New study course is absolutely mental, I am thinking about canceling it since I have 0 time left for WLED :( Would you make another branch with just the new UI (the 3 files index.js/css/htm only, you do not have to include the ESP side code to make it actually work). That might make it a little easier, I'm basically trying to get the diff between this branch and main down piece by piece until I can merge it completely 👍

[Aircoookie]

Reason I can't just copy UI files myself is that I would get attribution for all your changes which is not fair imo. And I did not find an easy option to merge only some files (without creating a huge change set by reverting changes to all other files)

[blazoncek]

I have an update on async preset loading.

WLED UI knows content of a preset so instead of sending "ps":X it can send complete JSON API for a preset (including HTTP API if that is the case) and alongside just notify core that preset has been applied (i.e. "pt":X). In such case a call to applyPreset() is not needed and correct state can be returned immediately to caller (ie UI). For other preset loading events a normal async loading does not constitute a problem since the caller (button, usermod, ...) does not care.

If an external source (i.e. not WLED UI) wants to change a preset by using preset ID I cannot see a reason why would it require a returned state to reflect exact preset content immediately since it can subscribe to websockets or periodically request a state to get the correct state at any given time (since WLED state may change from another source and in such case it would maintain incorrect state internally after another source changed WLED state).

So I would propose to change WLED UI to send complete preset API to WLED and pass a preset ID alongside API ("pt" from above). This may simplify preset loading and issues tied to it.

[blazoncek]

This has been superseded by #2737 Closing.