Component: Parsing, Pretty-Printing

This Issue exists to collect many items that relate to Dark's parser(s), pretty-printer(s), name resolution, etc.

Here's our current state:

• in dark-classic, we didn't have a parser used for user code
• that said, we did have a hacky parser used internally, for running many tests stored in .dark test files
• that parser was a simple wrapper around F#'s parser, and so our syntax was limited somewhat by what the 'upper' parser could handle

These are tasks currently available to be worked on:

• plug tree-sitter-tests-formatter in our repository, to (auto-) format the test files at tree-sitter-darklang/test/corpus, and fail in CI upon seeing unformatted tree-sitter test files (note: this task is probably the lowest-hanging-fruit here, with no blockers)
• generally, expand the tree-sitter grammar to match our language
  • each expansion requires companion work in the Dark code that consumes the resultant tree-sitter nodes (at time of writing, parser.dark)
• restrict usage of Builtins, so that only specific stdlib package functions may call upon them
• support aliases to unambiguously refer to package items while also presenting succinct code
• lots of formatting improvements
• try building tree-sitter and tree-sitter-darklang together. we could consolidate some code, etc
• get our parser to a point where it's usable easily by folks outside of ourselves
• revisit https://github.com/darklang/dark/pull/5381#issuecomment-2147575917

Once the tree-sitter grammar and parser has 'caught up' with our full language:

• throw away the F#-wrapper parser entirely

Once that is done, we can tackle the fun stuff:

• add ! ? to language, to assist with ergonomic error-handling
• refer to package items with a @paul.module1.module2-like syntax, rather than PACKAGE.Paul.Module1.Module2
• prevent conflicts of type names
  • e.g. users shouldn't be allowed to define a List type
  • in addition to preventing conflicts of existing types, keywords and other reserved word as well (i.e. Set)
  • potentially something in the name resolver
  • or maybe we allow users to use whatever type names they want, and deal with things closer to how Unison does

All of these tasks are worth some discussion, either here or in Discord, before starting.

This is a broad tracking issue covering parser, grammar, formatting, name resolution, and build work. For the explicitly identified lowest-hanging-fruit task, start with tree-sitter-tests-formatter and the test files under tree-sitter-darklang/test/corpus; inspect how CI is configured. Done means the formatter is integrated and CI fails on unformatted files.