ci(primitives): transition to new css primitives

[tmillr]

GitHub no longer distributes primitives in JSON format. Also, the names of the values (i.e. CSS variables) have changed. Most of the new names correspond 1-to-1 with one of the old names. Some colors have also changed slightly (e.g. fg-default), but otherwise remain mostly the same. See https://primer.style/foundations/primitives/migrating.

Source color primitives from @primer/primitives/dist/internalCss instead of @primer/primitives/dist/css/functional/themes as only the former directory contains the base colors (scales).

Convert new primer css primitives/variables directly to lua in .github/workflows/csstolua.lua (runs in CI). This script generates some debugging info in case an error occurs (which can be found in CI logs). Convert to a nested table structure for idiomatic usage in lua. The primitives table now provides type-hints via lsp, and accessing invalid names at runtime will throw an error. Append .default to names/keypaths which are too short and would otherwise collide with existing tables.

• scale no longer exists, but is still provided (by us) for backwards-compatibility and ergonomics. The new names are in the format of base.color.red[4] (for example to access scale.red[5]). The values in scale are 1-indexed for lua, but the original upstream names (in base.color.*) are 0-indexed and left untouched.

• scale.gray no longer exists, use scale.neutral in its place

• *.subtle variants no longer exist, see the link above for the corresponding replacements

[tmillr]

Ideas and TODO

• [ ] Tests
• [ ] Types to catch invalid references before runtime (LSP) (e.g. implement types in palette files, make spec well-typed). The idea is to help prevent assigning a table to one of the (leaf) keys of a spec at development-time (since the keypath for some of the primitives have been extended). Impl types within generate_spec().
• [ ] Type-check spec at runtime? Ensure that valid values are assigned to well-known fields of a spec (this could include user overrides as well).
• [ ] Also run primitives workflow when its workflow file has been altered in a pr (prior to testing) so that those changes can be tested too (making sure to if-guard against pr creation, which shouldn't be done in this case). Also maybe run it on pushes to main as well (again only if/when the workflow file changed)?