Remove WebWorker code that is now in cockle

[ianthomas23]

This is an attempt to upgrade from cockle 0.0.5 to 0.0.7. The WebWorker code is now in cockle and hence needs to be removed from this repo, making this much simpler.

It is not yet working as the WebWorker is not yet being initialised correctly. Originally I thought this was a problem with the worker.webpack.config.js but I don't believe this is required any longer as the normal build process creates the webworker JS file in the correct place in the _output directory. I have confirmed this by replacing the cockle shell_impl.js with something much simpler that has no dependencies and just writes some debug messages to the console, and that works fine. So the problem appears to be with webpack trying to load @jupyterlite/contents which is seems to do recursively. I am experimenting with setting this package as one of the singletonPackages.

[ianthomas23]

This now works, the singletonPackages was a red herring.

Now we are using the WebWorker shell_impl.js code that is pre-bundled in cockle 0.0.8 and extra webpack config in webpack.extra.config.js that is used by the labextension build process to use the prebundled worker code rather than bundling it itself. The approach of bundling it itself, which happens here by default if not overridden, works for everything except the use of @jupyterlite/contents to include DriveFS, so the longer term solution here should be a different webpack config to deal with just this problem such that we can remove the need for cockle to pre-bundle anything.

Also this includes an extra build stage to copy the WASM files and their associated JS wrappers into the correct directory so they are served at the expected URIs for dynamic loading using importScripts.

To try this out locally still requires the use of

jupyter lite serve --LiteBuildConfig.extra_http_headers=Cross-Origin-Embedder-Policy=require-corp --LiteBuildConfig.extra_http_headers=Cross-Origin-Opener-Policy=same-origin

We still need some solution along these lines for the hosting of the demo site in github pages.

[ianthomas23]

This path is currently hardcoded and works OK for default installations. I am not sure if the extension path is configurable and if so, we'll need to obtain this dynamically at runtime.