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)?