Use WebWorker

[ianthomas23]

With this PR a shell always runs in a WebWorker rather than the main thread. Up until now the WebWorker code has been in the UI projects (JupyterLite terminal extension and cockle-playground). It makes more sense to have it here so that there is only one copy of it and allows the UI projects to be relatively thin wrappers of cockle. Also, it is important that the shell runs in a WebWorker to allow us to dynamically load WASM commands rather than the current approach of compiling and linking them in the NPM package.

There are now 3 shell-related classes. Shell is the external interface to a shell, and runs in the main thread. ShellWorker runs in a WebWorker and communicates with the Shell via comlink and also a SharedArrayBuffer to provide buffered stdin whilst WASM commands are run. ShellImpl is the actual shell and is mostly unchanged from the previous Shell class.

There are extra IShell.IOptions used when creating a Shell, mostly relating to initialising the WASM filesystem. This includes a driveFsBaseUrl to create a JupyterLite DriveFS to access the files displayed in the JupyterLite file browser, and there are also initialDirectories and initialFiles to create which are mostly used for testing.

Much of the test suite has been ported, but some tests remain commented out for now. The playwright tests can directly access a Shell in the main thread and pass text in and get text output, and they can also access some of the low-level functions like tokenize and parse by directly using them without a WebWorker. But accessing other objects of the ShellImpl in the WebWorker is not currently possible, so probably the commented-out tests will eventually be rewritten to access the main thread Shell. It would alternatively be possible to run some units tests in node without a WebWorker, but this has limited use as when the WASM commands can be dynamically loaded, which is intended to be soon, they will only work in a WebWorker.

This has been tested against cockle-playground but not the terminal extension as the latter needs larger changes.

[jtpio]

Wondering if we should track removing this field at some point, as it usually better practice to not have to use it.

[jtpio]

What change in particular required enabling skipLibCheck?

[ianthomas23]

Without it I see complaints about @rjsf:

node_modules/@rjsf/utils/lib/types.d.ts:102:37 - error TS2339: Property 'autocomplete' does not exist on type 'HTMLInputElement'.

102     autoComplete?: HTMLInputElement['autocomplete'];
                                        ~~~~~~~~~~~~~~

node_modules/@rjsf/utils/lib/types.d.ts:735:37 - error TS2339: Property 'autocomplete' does not exist on type 'HTMLInputElement'.

735     autocomplete?: HTMLInputElement['autocomplete'];
                                        ~~~~~~~~~~~~~~

node_modules/yjs/dist/src/types/YXmlFragment.d.ts:163:36 - error TS2304: Cannot find name 'Node'.

163     } | undefined, binding?: any): Node;
                                       ~~~~

I assume it appeared because I added use of JupyterLite DriveFS and that brings in more dependencies, but I don't know.

I would rather not use the option, but I couldn't find a quick fix.

[jtpio]

Opened #41 to track this.