chore: add new base palette colors & use them in pentaho+ theme

[zettca]

• Adds new "base palette"/color matrix (we need to give this a proper name 😅) to the styles package
  • Available from theme.palette - values are not injected as CSS vars
• Align the current tokens (positive, atmo<X>) with the new palette in the the Pentaho+ theme
• Hoist utility tokens (backgroundColor/containerBackgroundHover) to the tokens declaration
• Refactors & improvements

[zettca]

If we spread the "base palette" colors here, they'll be injected as CSS variables and available in theme.colors.*, but these tokens do not vary depending on theme.

1. Should we inject the CSS vars?
2. Should we make them available only on the "runtime" theme object (from useTheme)?
3. Should we keep it as a separate static import?

1. seems wasteful, and if we don't want to promote the usage of the palette colors directly 3. might make the most sense

[MEsteves22]

The "base palette" are the colors added to colosPalette.ts, right?

Doing only 2 means that users will only be able to use these colors inside a function component or hook (otherwise they'll need to "hack" their way into using them somewhere else). I'm not 100% comfortable with that.

We could do 3 but it seems a bit confusing to me (and to users) to import colors from two different places: theme and static imports.

I agree that 1 seems wasteful, and we would be polluting the stylesheets with unnecessary CSS vars. However, it makes sense to have access to these colors when using theme. Can't we do a mix of both inside the theme object? Some colors are CSS vars and other ones are static values? For example we have utils like spacing or alpha that are static.

[zettca]

Yeah, we could optimize which colors are injected as CSS vars 👍

[zettca]

Tokens are available from theme.palette (alternative suggestions welcome)

[MEsteves22]

LGTM 🚀

[MEsteves22]

Some questions/things to think about:

• pentahoPlus theme mapping: to review after DS provides a mapping of their own.
• White labelling feature for the new palette not possible at the moment (the palette is static).
• Some confusion (at leats on my side) about the themes: DS3/DS5 color tokens used inside the pentahoPlus theme. New palette tokens not used/available.

These are just some questions I had after reviewing the PR, but they are for the future. I know these were not in the scope of this PR 🙏

[zettca]

pentahoPlus theme mapping: to review after DS provides a mapping of their own.

Yes, this is just initial work 👍

White labelling feature for the new palette not possible at the moment (the palette is static).

You you mean light/dark themes? Users can/should be able to do that by overriding a few "semantic tokens" (which do don't have yet) - they shouldn't need a "full palette" of their own
For instance, MUI has a large palette of colors; but to create your own theme, you just need to override a few "semantic tokens" (eg primary, secondary, text, warning, etc.)

Some confusion (at leats on my side) about the themes: DS3/DS5 color tokens used inside the pentahoPlus theme. New palette tokens not used/available.

One more reason to now inject the "palette" tokens in theme.colors.* yet IMO 🤔 (besides not being recommended to use directly (as they're not themed))