Refactor extension

[doriable]

This is a refactor of the LSP implementation for the extension:

• Rename BufContext -> BufState, export as a global, and centralise extension logic in BufState: rather than context, this is more of a state for the extension itself. It was previously instantiated and plumbed through all commands, but since the state is global, it made sense to change the pattern and export it was a global variable that could be imported wherever it was needed. Most of the extension state logic (e.g. managing the buf binary and the language server) have also been centralised to BufState. Commands are now simple functions exposed to the user that call functions on BufState.
• The refactor of BufContext simplified the Command structure.
• Consolidate find-buf and install-buf: find-buf and install-buf were closely coupled, and we wanted to expose a clear command to our users in the form of an "install" command. Extension activation uses "install" as well.
• Rather than restart-buf and stop-buf, we now have startLanguageServer and stopLanguageServer: this is a small semantic change, but it helps the commands map closer to the language server states, LANGUAGE_SERVER_STARTING and LANGUAGE_SERVER_STOPPED. Also those commands only control LSP functionality using buf.
• Use string[] and as const as literal value types instead of enums: this is just a pattern that was preferred, and allows us to export/import less types.
• Revamp testing: we wanted to do as little mocking/stubbing as possible in our tests, and we generally want to test integration flows. The testing has been reworked and documented in DEVELOPMENT.md. All tests are either using the VS Code testing CLI or Playwright. Also added testing for LSP functionality in Playwright.
• Clean-up .vscodeignore to reduce the number of files we were including that were not needed at runtime.

There will be a follow-up PR containing a new CHANGELOG and README. We'll also be updating our lint + deps in a follow-up PR.

[mcy]

Care to explain why we're doing this typeof nonsense? I expect non-TS experts to have to look at this, so it'd be best to explain anything especially tricky looking (such as not using an enum).

[paul-sachs]

Basically to avoid enums. Enums generate some pretty horrendous javascript, and iterating over them is confusing at best (and erroneous at worst). This bypasses that by using string literals instead and let's typescript enforce validity that way. A slight sacrifice to that is this typescript logic to get the possible values of that array.

[doriable]

I added a comment in status.ts and command.ts explaining basically what Paul communicated above so that we have some in-line documentation for why we do this.