Signed-off-by: Elad Kinsbruner <kinsbruner@campus.technion.ac.il>

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.

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...

Changed codename, seems more temporally fitting.

This is broken due to `load_plugin` not being implemented yet.

We need to think about how to fix that, likely just updating our
library manager to include `META` files for the plugins should work,
but we need to find out.

The main relevant change for us in Coq 8.16 is that Coq now loads
plugins using the `Fl_dynload` API.

So now Coq, will make a request for `coq-core.plugins.ltac` instead of
`ltac_plugin.cma`.

`Fl_dynload` is a wrapper over `Dynlink.loadfile`, but will check
`META` files for dependencies, and if plugins `A` depends on `B`, will
load `B` first.

This may be a problem for us, we need to figure how to handle
that.

One approach couuld be to replace the `Dynlink.dynload` stub with the
proper javascript implementation so the `Fl_dynload` uses it implicitly.

Another (temporal) alternative to get this working is just to ignore
deps and implement `Ml_top.load_plugin` with a mapping. I have done
that as Coq 8.16 still includes a "legacy" mode, which should work for
some plugins, but not for all of them (coq-elpi for example requires this).

The 3rd approach would be for us to reimplement `Fl_dynload` by
locating the META files and parsing them, or storing this metadata in
some other fashion.

- Migrated patches for 8.14.
- Up wacoq to 8.14 in docker image
- install: 8.14 requires `coq-core` and `coq-stdlib` to be installed.
- Set version 0.14.0.

Listed `coqoban` in affiliated packages.

Closes #241.

This should nicely support M1-based OSX ; unfortunately, it required
loosening the constraint on `ppx_deriving_yojson` as to make it
co-installable with `ppx_import`, but that's a minor issue.

Note the new option system for OCaml Opam packages, thus selecting a
32bit compiler is done differently now.

This is just a basic building setup, for linux at the moment.

Github Actions is way more powerful than travis, so we can improve
many previous things of the setup, concretely:

- re-add OSX build
- generate a docker image
- set a job for each addon, or create a push event so addons are built
  on their own repos

Closes #224

Thanks to Jason Gross for the help with the SerAPI action.

Thanks @mdnahas :D

(+ tiny style fix)

We also bump some other libraries as to reduce non-deterministic
developer switches.

Nothing too remarkable, code-wise, but a big change upstream is the
addition of `zarith` as a hard dependency.

TODO:

- update addons

When building on macOS + arm64, choose OCaml 4.10.2 automatically
(4.08.x is not available).

For batch compilation, compile with `Stm.VoDoc` type.
Terminate worker after batch finishes up.

This seems needed for Coq 8.12

This includes some bug fixes and the upstreaming of Shachar's Str
stub, so we can remove it.

Previous behavior was to mark the whole sentence.
Now, the location reported as part of `CoqExn` is used.

Closes #141