Add ddlog v2 implementation

[Kixiron]

This is a lot of code, but luckily a lot of it can be ignored or categorized

• xtask/: This is where all of the xtask stuff lives, run cargo xtask to see a help menu. It deals with setup and code generation at the moment but will probably be extended in the future. Useful commands are cargo xtask setup (setup and initialize your local repository), cargo xtask codegen (run code generation) and cargo xtask codegen check (check that the generated code currently within the repo is up-to-date)
• editors/: This is where the editor-sided code lives for the LSP integration, currently there's only a very basic stub in there
• crates/ddlog-utils/: Utility types, functions, etc. Holds random utilities for other crates so that we don't have to copy+paste things into each crate or get thrown into some scary dependency loop
• crates/ddlog-diagnostics/: A facade crate written to allow the rest of our compiler/lsp be agnostic around the internal details of our produced diagnostics. Currently we use ariadne as our error backend, but the nice thing is that we could change that without affecting the rest of the compiler. This also gives us the flexibility to be able to easily emit both terminal based errors and lsp-sided errors.
• crates/ddlog-syntax/: The syntax tree and parser for the compiler and lsp
  • ast/: The generated concrete syntax tree definitions along with some utilities for them, mostly generated code
  • parser/: The actual parsing code, the notable files being expr.rs, stmt.rs and item.rs. The rest is pretty much just plumbing and stuff to make things nicer to work with
  • syntax_kind/: The syntax kind definitions, mostly generated code
  • validation/: The parser is overly flexible (on purpose), so we parse more things than are actually syntactically valid. This is what the validation module is for, it's a series of passes over the produced ast that produces nice diagnostics for syntax errors. The idea behind being overly generous with what can be parsed is that it works in favor of error recovery and produces better, more helpful errors, which leads to a better user experience. It also means that we don't have to stop entirely if the user adds, for example, an extra comma between function arguments. Instead, we can continue further stages of the pipeline to try and give any further errors there instead of being halted at the invalid syntax
  • tests/: Test suite for the parsing and validation machinery. Tests are written inline within the actual code and then put into files by cargo xtask codegen so that they can be run, this is where the generated files live. tests/filetests.rs is the only "real" file here, the rest are just generated files containing the source text of a test and the expected output it'll produce
• crates/ddlog-lsp/: The language server side of things, currently can be pretty much ignored since it's not in its final state at all. Currently it holds a lot of the glue that pipes different stages of the compiler together, but I'm going to split them into different crates since that'll make things cleaner. Currently of interest would be ddlog-lsp/src/providers/hir, that's where the cst->hir translation currently lives. The hir will be the next step of the compiler pipeline, it'll be where type checking and some semantic checking happens before being converted into a lower level form and which can then be fed through our final codegen backend
• crates/ddlog-driver/: Basically nothing but a stub that calls everything else and bundles it into an executable, think of it as the entry point to both the compiler and lsp

[mihaibudiu]

Can this patch be broken down into a series of patches that can be independently reviewed?

[Kixiron]

Not easily, that's why I added the breakdown