Implement Custom TS Worker

[Cobular]

Closes #289

PR 1/2, this commit contains a minimum viable custom TS worker. Next PR will include the demo from https://github.com/NASA-AMMOS/aerie-monaco-editor-customizations, of validating timestamps.

Summary

This PR creates and integrates a custom typescript worker for Monaco that does not require maintaining a fork of Monaco, does not require redoing any of the hard language server work, and also taking the blessed path from Monaco for doing this sort of thing. It will allow us to add new diagnostics and should allow us to differentiate different editor instances on the same page!

How it works

We get to create a subclass of the Monaco TypeScript worker in https://github.com/NASA-AMMOS/aerie-ui/blob/5c9130f7ab85cc3682a8715cb6a24803cf6ea2f0/src/utilities/customTS.worker.ts and conditionally override only the methods required for our work. Currently, I have a barebones subclass with just a few methods implemented, although you can just ctrl click on the types to see the other possible methods.

We still load the original Monaco TypeScript worker code straight out of node_modules as before, so we will automatically get any backend changes included in changes when we update Monaco. This method, of providing a subclass factory function, is the intended (if very very poorly documented) solution from the Monaco team for doing this.

Build System Changes

Doing this (specifically specifying a customWorkerPath for the typescript worker defaults, which loads our subclass factory) requires that the original worker be launched in classic mode, which is where we run into issues with Vite. It will not properly bundle worker files for this mode in development no matter what you do, so we require a new Vite plugin that hooks into file changes and rebuilds the worker on changes, then forces a reload.

This currently works pretty well, with the obvious downside that it forces a full page reload and the less obvious issue that it will not automatically reload on changes of files imported by the workers, just on the worker files themselves. I don't believe we can work around the page reload issue easily due to the realities of worker lifetimes. I may be able to figure out how to get esbuild to tell me what other files need to be watched with some more effort, but right now I'm not sure that's worthwhile given that this stuff probably won't be changed all that frequently and we can just cmd+r if you need to.

Pain Points

Currently, there's one big pain point - Worker Typing. Because of the issues with the Monaco build process, there is no way to get the relevant types for the TypeScript Worker class from the Monaco project's release artifacts, they must come from an intermediate build step and be manually copied. I have done that already, however it is possible that the reality of the underlying data may drift from the types at some point in the future. I believe the only real fix here is testing, as we'd need to get Monaco to make a rather substantial change in their exported interfaces.

Additionally, there's a bit of weirdness in return types - the Diagnostic type in typescript is not actually JSON serializable due to internal references to file objects, so despite the types working out, you need to ensure you match the type definition for Diagnostic in the module monaco/languages/typescript which includes only the fileName parameter for file. (this will make more sense when I create PR 2/2 with the time string format validation).

[camargo]

🚀