feat: architecture and lsp features

[psteinroe]

This pr is a rewrite of the project and implements the base architecture for the language server, its data model as well as a few proof-of-concepts for different language server features:

• hover
• autocompletion
• lint
• run command (execute statement under cursor)
• inlay hints (untested)
• typecheck

The goal of this work was to prove that implementing a language server on top off the rather hacky parser is doable, and that is now completed. Still, we have not reached a usable state yet, because

• (1) the features above are implemented as a poc only, and most of them need some love. I will document todos for each of them and hope that the community will be able to contribute here.
• (2) the parser is still the one from end of last year, just a bit better structured. Making it stable is what I will focus on next. it's just "work", nothing that needs to be researched etc. Part of this will also contributing some proc macros to pg_query.rs so we can skip some of the (slow and hacky) workarounds.
• (3) configurations are completely missing. we want to user to be able to disable lint rules etc
• (4) client implementations are missing. support for vscode and neovim is required.

Besides that, there are other areas I want to improve the code in before declaring this language server usable.

• documentation, documentation, documentation
• right now, the Workspace struct is handling just everything that is stored eg diagnostics. all queries (e.g. hover) are currently implemented directly within the language server. I want all features to be handled in the workspace crate to make it easier to use from a future cli and also easier to write e2e tests. I am targeting a design similar to biome, where both lsp and cli act as a client to the same daemon server. this will also make it much easier to test everything e2e.
• the diagnostics crate should be exporting a trait, not a struct, alongside of a bunch of macros to easily declare any struct as a diagnostic. once again, I am looking at biomes implementation to copy from.
• profiling: I have zero experience in this, but especially when we have an easy-to-test workspace crate with all features we should be able to profile and benchmark the language server.

this pull request is huge, and I dont expect anyone to look through the entirety of it. areas that are worth a review though are:

• server.rs in pg_lsp, especially everything around debouncing and change handling (did_open, did_change). my goal with this was to debounce the "heavy" computation after a change while computing directly when the user saves the file.
• pg_base_db and pg_workspace, especially everything around change handling. the idea here is to cut a source file into individual statements and only recompute what actually changed. so if the user types within a statement, we only compute diagnostics etc for that single statement. I am pretty confident that this works well, but would like to hear someone's opinion on the way its handled especially around multi-threading, usage of DashMap etc

ToDos before merging

• bring back tests from archive dir
• documentation for each crate
• new readme
• issues for roadmap, todos etc