Compile F# backend into WASM

[pbiggar]

This is to track progress of compiling the Dark execution engine (interpreter plus most of the standard library) to WASM to run in editor/browser. (In the OCaml version, this was done by js_of_ocaml, in jsanalysis.ml).

It is currently working in some form in https://github.com/CedricRup/dark/tree/blazor-webworker, and "just" needs to be adapted to load as part of the client.

Overall end state:

• When the editor loads, it should load the F# execution engine in a web worker
• when receiving a message from the client, it deserializes it, executes it, and reserializes the response
• during deployment, the compiled engine gets uploaded to the CDN
• we can run it in the editor by adding a feature flag
• integration tests pass with the feature flag

Current ocaml implementation:

• appsupport.js creates the main thread and the worker constructs for communication
  • window.Dark.analysis on the client side
  • window.AnalysisWorker is on the Worker side
• window.analysisWorker is made up of AnalysisWorker.ml (via bucklescript and browserify) and jsanalysis.ml (via js_of_ocaml)
• window.Dark.analysis.requestAnalysis makes the request to the web worker from the client and receives the response. It's called from within the client

What we currently have in F#:

• src/Wasm/wwwroot/index.html - has the config for how to call BlazorWorker.js
• src/Wasm/wwwroot/BlazorWorker.js - loads in the main thread, creates a worker, sends a request to it. Loads all the dlls, etc
  • inits the worker with window.BlazorWorker.initWorker()
  • has controls to postMessage

Tasks:

• Port over the existing work from https://github.com/CedricRup/dark/tree/blazor-webworker
• Find a good place to load BlazorWorker.js as well as the config in wwwroot/index.html
• load Blazorworker.js at page load time
• In window.Dark.Analysis.requestAnalysis, use a feature flag to maybe call BlazorWorker.js instead of analysisWorker
• serialize and deserialize correctly
• return valid results for both handlers and functions
• investigate other ways to config BlazorWorker.js
• figure out whether a copy of blazorworker is the right thing to do
• remove changes between copy of BlazorWorker.js and upstream
• check the output of analysis is the same for OCaml and F# workers
• remove duplication from initializeBlazorWorker (make file list implicit)
• find out what all the files are that need to be deployed
• deploy files to CDN
• what needs etags?
• what about packages?
• merge EvalService into Wasm
• move dependencies to paket
• find out what's going on with TaskOrValue.Delay
• reenable storeFnResult in Interpreter.js
• determine performance impact of wasm, find optimizations if needed
• deploy in "published" form, and trim
• find cause of runtime error

[pbiggar]

I moved the remaining issues to their own tickets.