- don't rebuild the cli stuff when the frontend/backend changes
- make tests work again

This is not perfect but it works (and it is much faster).

For some reason I couldn't make `fflate-unzip` work with ESBuild, so
I've placed a copy and tweaked the exports.

This is a large build-time improvement, moreover we can get rid of a
lot of troublesome code regarding how to manage assets.

`esbuild` has proven a great tool so far.

Tested with both backends.

We still keep the CLI and the WASM backend on webpack, the idea is
to move them to esbuild in subsequent commits.

CLI should use a native Coq instead, it is super-slow.

We also disabled the `collab` and `ide-project` builds for now,
re-adding before merging hopefully.

The compatibility story with user .html pages needs to be revised,
IMHO as this is a foundation for the LSP backend this is the time to
drop support for some patterns we had in the past.

Doing it here as the CI for dependabot seemed to have a problem.

Closes #312 closes #313

All wasm binaries are read from `node_modules` directly, so there is no
need for a `bin/` directory (this was a hack).

The deps are collected in a meta-package `wacoq-deps`, which is
published to NPM separately and should not change often.

Will gradually move parts from the other repo, wacoq-bin, to `backend/wasm`.
This will allow some code reuse between the backends.

This is rarely used live, and should allow us to make progress towards
the common protocol a bit more easy.

We reorganize jsCoq's source code as to be more modular, in particular
we start to place backend files under the `backend` directoy, and
frontend files under `frontend`.

Code as it now does work, note however that still quite a bit of work
is needed. In particular, the headless frontend should get its own
directory, the coq-jslib directory should go away, use more types,
etc...

Newer webpack{,-cli} support this.

In princple, should change Ronin to not rely on the literal name
of the constructor.

The bundle (`.bundle.min.js`) is now needed for the menu.

Still, both don't fully work, needs more research as to witness what's
broken.

Well not quite, the `dsp` dependency needs to be resolved.

MathJax added as an NPM dependency instead of using CDN.
(Because same-origin policy stuff.)

Completely bare-bones, no UI yet.
Required quite a lot of the usual polyfills.

Bumps [terser](https://github.com/terser/terser) from 5.7.1 to 5.14.2.
- [Release notes](https://github.com/terser/terser/releases)
- [Changelog](https://github.com/terser/terser/blob/master/CHANGELOG.md)
- [Commits](https://github.com/terser/terser/commits

)

---
updated-dependencies:
- dependency-name: terser
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>

As suggested by @hannelita.

Allows multiple jobs to invoke the SDK in parallel. If the SDK is not installed,
the first to lock the file will carry out the install.

Included `index.html` and a `package.json` to show how to load
and run the resulting package.

Also added `playful.html`. (Which is a bit unrelated.)

+ updated Mocha (npm audit stuff).

Previous package, `vue-context`, is abandoned.

Consolidated Webpack config in a single file, as is more common for
Webpack.
Provided npm scripts for running it as usual.

This was too hasty: vue-loader@16.x only works with Vue 3.

Some NPM audits.

Now `stream-browserify` is needed as a dependency.

This is phrased as an "addon"; I think that not only libraries can be
"addons" but this kind of interop UI functionality should be as well.

It does not mean that UI addons should be built outside of the jsCoq
source tree like mathcomp & co.
If they are small enough, they are ok where they are in `ui-js/addon`.