Feathers theme generator and replacement of hard-coded light theme

[gagnus]

This is a replacement pull request for #24726 which was a hard coded light theme.

Instead this pull requests adds a theme generator which takes a series of Oklcha colors (expressed as a hue/chroma and an array of lightness values) and generates a theme from that, using a mapping from token to "Slot" (which of the Oklcha colors with which lightness to pick.

Adds a light theme.

Objective

• Wanted to make the theme editable but the current way of having a long list of tokens per theme wasn't sustainable, so boiled it down to "neutral" "text" and "accent".
• Also gets rid of heavy use of alpha to generate new shades, instead these are encoded into the theme making controls more predictable (even though text input doesn't look right yet)

Testing

• Tested using feathers_gallery

---

Showcase

This image compares main (left) with this change (right)

This is the current set of colors (matching figma as much as possible while keeping hue/chroma consistent through the sets)

This is the current state of light theme using this

This is a control gallery I've been working on showing each control and each state on a "subpane" panel bg

This is the same gallery on the lighter "group" panel bg

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[viridia]

There are a few cases where we are running up against some limitations of the feathers theming framework: specifically, feathers currently doesn't support "contextual theming", that is, colors that adjust based on the background. This is a not uncommon feature of react / css theming frameworks which allows theme variables to be locally scoped, so that widgets placed on a panel with a lighter background can be increased in brightness, maintaining contrast. Doing this in feathers would require the theme calculations to walk up the ancestor hierarchy, a complication we decided not to tackle at the time.

The editor figma mocks show that text inputs, in particular, have different background colors depending on what flavor of grouping container they are in. Using a single fixed color doesn't work: either the input fields disappear entirely when placed against a lighter (group-level) panel, or if made darker, become overly contrasty in other contexts.

To work around this limitation, we decided to go with an alpha-based approach for text inputs. A carefully chosen alpha value produces results that are nearly indistinguishable from the mock images - at least for the dark theme. I suspect that this strategy won't work as well for lighter themes.

The other uses of alpha (button hover and so on) I don't care too much about other than they be subtle - I mainly wanted to avoid exploding the palette with lots of additional shades.

[gagnus]

Completely get it, the problem with using alpha is it produces very different results with different themes and it is essentially adding new colors just by the back-door (and often its N*M new colors rather accidentally where N is colors and M is background colors). The figma mocks are a little ambiguous about what happens to controls on the "group" background, often they do seem to deliberately disappear the background and use a border, probably need some work there in figma to work out exactly what's wanted on the two different backgrounds. I've left a slot open (neutral2) which we can tune up to work well I think whichever way we go with it.

[gagnus]

Not sure what to do next with this one @viridia and @alice-i-cecile. I think it's right and we should get it in and fix forward the issue of controls on groups (none of which are broken with this since the colors are distinct) when we have design for what they are supposed to look like sharing a color.