Add compiler and runtime support for generating pure JS as an alternative to C/Wasm

[chrispcampbell]

Since we have refactored the parse and code gen phases, it is now more feasible to add support for generating JS as an output format. A few considerations:

• The benefit of generating JS is that it can reduce the complexity of getting started with SDE, since the user doesn't need to worry about getting Emscripten set up or working with multiple plugins (wasm and worker plugins, for example).

• It can also open new doors for rapid prototyping with SDE: we can potentially build a REPL-like environment for learning SD modeling entirely in the browser, no local toolchain required.

• Pure JS code won't likely run as fast as the existing Wasm-via-C code, but when working with smaller models, JS should provide sufficient performance.

[chrispcampbell]

Summary

I'll be filing a PR for this work shortly, and will be merging it to the main branch shortly thereafter. However, I'm not planning to publish SDE packages to the npm registry until this and a few other upcoming branches are merged, that way Todd and I will have a chance to review everything and make sure it all fits together.

This branch focuses on the compiler, cli, and runtime changes that allow for generation of a plain JavaScript model. There are some changes to the APIs and sde command line interface options, which I've summarized below. Most of these will have little to no impact on existing users of SDEverywhere, especially if you work with the default template generated by the Quick Start instructions. The PR that follows this one will include changes to the build and plugin packages to allow for setting JS as the code gen target at that level; see #478 for details.

Changing to JS as the default code gen strategy (instead of C/WebAssembly)

One goal with this work is to make the JS target be the default behavior, since it requires no additional dependencies to build a working model. All you need is your existing Node.js installation, so this will make it easier for new users to get started with SDEverywhere. This is in contrast to building Wasm, which requires Emscripten (which requires Python to install); this has been a pain point for users who are new to SDEverywhere. Generating Wasm is still relatively easy to get set up using the @sdeverywhere/plugin-wasm package, but should now be considered an opt-in / value-add thing for projects that benefit from the performance benefits of WebAssembly rather than a hard requirement for using SDEverywhere. In other words, users can get their project up and running quickly using the JS target, and can easily add plugin-wasm later if desired.

Simplified initialization

I've made a number of improvements and simplifications to the generated models and to the runtime APIs that make it easier to initialize a model, regardless of whether it is in JS or Wasm format. These diffs illustrate how the initialization process has been simplified, and the same code works if generated-model.js contains a plain JS model or a Wasm model:

Changes to sde arguments in @sdeverywhere/cli package

• added --outformat={js,c} argument to sde generate (the old --genc argument is deprecated; replaced by --outformat=c)
• added --genformat={js,c} argument to sde build, sde run, and sde test commands

API changes in @sdeverywhere/runtime package

• removed WasmBuffer from public API; it is now an implementation detail
• removed WasmModel and initWasmModelAndBuffers from public API; these are now implementation details
• removed createWasmModelRunner from public API; use createSynchronousModelRunner instead
• added JsModel to public API; this interface declares the shape of the JavaScript module generated by the SDEverywhere transpiler, but most developers will not need to interact with this directly; use createSynchronousModelRunner to create a ModelRunner from a JsModel
• added GeneratedModel type to public API; this is the union of the JsModel and WasmModule types that are generated by sde generate
• added createSynchronousModelRunner to public API; this can be used to create a ModelRunner from a GeneratedModel