So that we can create both jsCoq and waCoq packages.

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

A flag `backend=wa` can now be passed to `scratchpad.html` to set the
`JsCoq.backend` config to WA.
Given an installation of `wacoq-bin`, this actually works!

These are obsolete. See github.com/jscoq/addons.

The former is used to generate the symbol database for autocomplete and
contextual info.

Broken by previous refactor.

Including tweaks in a few other places.

Makes more sense and also cleaner.

Modified `doc_options` to accept lib names as "."-delimited strings.

And so it begins.

`SearchResults` now carrying `qualified_name`s instead of `full_path`s.

Refactor `FormatPrettyPrint` (again)

In cases where the element has a padding, as is the case with `div.coq-env`.
The unit-test gallery has been updated to reflect this situation.

Trying to be more faithful to what `Format` does:
- take into account offset parameter defined on boxes.
- adhere to left margin of containing box, when breaking lines.
- be more declarative via CSS.

I think this would handle #126.

Closes #203.

Each snippet is now shown both before and after
break adjustment.

Symbol format has changed, but respective methods have not been updated.

In the landing page, due to the existence of bootstrap CSS.

Some of the instructions are duplicated from the README, but that's ok.
The manual is not yet complete with all the features, but at
least addresses #207.

Closes #207.

Closes #241.

Include full module path.
Improve the presentation when multiple matches are found.

I'm merging because the Dockerfile is now good enough for both CI and non-CI use. The SDK is still borked because 32-bit. Merde.

These were created using the waCoq CLI from Coq 8.13.2 standard library.
When more than one lemma matches a name, multiple results are shown.
Not clear why there are duplicates (i.e. same long name).

[build] Bump required compiler version to 4.12.0

For SF, when volumes are built separately and incrementally.

(For quick testing only)

This still requires considerable work, but when ready it should
solve parts of #69 and #121.

As for now, we don't push the image to a registry yet; we ought to
decide:

- when to build the docker image [maybe only on main branches]
- where to push it
- what to include
- a standard setup for addons CI, so they pull the image and then
  build and publish their own package
- how this does integrate with npm, maybe we shouldn't push the image
  but just a npm package built using docker [so addons do get the
  correct binaries to push to npm too]

Based on:

https://github.com/marketplace/actions/build-and-push-docker-images

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.