parse from the flux-lsp wasm library blocks the main thread; it shouldn't

The `parse` and `format_from_js_file` functions from the `flux-lsp` wasm library are synchronous functions. On the surface, that seems fine, because they are CPU bound functions, so would block anyway. However, they parse strings of unknown length and walk ASTs of unknown length. A single call to `parse` could block the browser functionality indefinitely if the flux script is sufficiently large, but even with small flux files, at a certain count of flux files, it can have the same effect. For instance:

```javascript
const flux = 'from(bucket: "myBucket") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "myMeasurement")';

for (let i=0; i<1000; i++) {
const ast = parse(flux);
}
```

The following script could also cause issues, with a small flux file. In this case, you could batch out these iterations a bit to yield back to the event loop, but if you have 1,000 separate components all emitting an event that does `parse`, you don't have control flow to batch that up.

The right solution with the current api provided is likely to wrap `parse` in a web worker. This isn't ideal, but doing CPU-bound tasks of unbounded length should never have in the main thread anyway.

DOD:
- `parse` and `format_from_js_file` from the wasm only ever execute in a web worker.
- There are corresponding asynchronous `parse` and `format_from_js_file` functions that can be used from the main thread.