Reference reactor-ts as module

[lhstrh]

This PR changes the build process to, rather than compile generated code in conjunction with the reactor-ts code, compile separately and import reactor-ts as a module. In principle, this flow would enable building reactor-ts just once and reuse it for all tests, but we currently don't do this (yet). Once reactor-ts stabilizes and has regular releases, it should suffice to treat is as a normal dependency and pull it from NPM like all other dependencies. Then, pnpm can take care of caching, which should speed up build times considerably.

[petervdonovan]

• Declaration files do not support exporting classes with non-public members: Support for all type features in declaration files. microsoft/TypeScript#35822
• Some mild refactoring may be necessary so that we can be selective about what is/is not exported (i.e., no internal.ts)

Such issues as these may delay progress for some days.

[petervdonovan]

I just ran into an issue where the generated directory for Minimal.lf consumes over 300 MB 😅 which is why we ran out of disk space on Windows in CI. Even in master it uses 130 MB, so instead of reverting I'll try to find a fix.

[petervdonovan]

Okay, I followed through with what I talked about with Marten (not bothering to pre-bundle the runtime or to install its dependencies) and the tests seem to be passing now, except for the LSP tests. I will try to get this done this weekend, although I might be sidetracked/delayed by the fact that the language server vscode extension no longer builds for me.

[lhstrh]

Added some minor comments...

[petervdonovan]

Here is the result of running npx depcheck in the src-gen folder for Minimal.lf:

Unused dependencies
* @babel/node
* @babel/plugin-proposal-class-properties
* @babel/plugin-proposal-object-rest-spread
* @babel/plugin-proposal-optional-chaining
* @babel/plugin-transform-modules-commonjs
* @babel/preset-env
* @babel/preset-typescript
Unused devDependencies
* @types/google-protobuf
* @types/node
* @types/uuid
* ts-protoc-gen

The dev dependencies are not even installed by our code generator, I believe, so they should not matter for compile times. I do not require any dependency removals to be low-hanging fruit. Any protobuf-related dependency removal will require us to edit the package.json file conditionally in the code generator, which will add complexity to it. As for the build system -- I personally have had difficulty with the build system and prefer not to tinker with it further right now.

Is there any reason not to merge this as-is?