Add WebAssembly build, cockle and terminal deployments, and testing

[ianthomas23]

This PR adds the ability to create a WebAssembly build of the local git2cpp source code, create cockle and JupyterLite terminal deployments to manually check they work, and test via pytest.

Most of it is in a new wasm directory to keep it isolated except for some monkey-patching in the top-level test directory because pytest wants it this way. I've tried to keep the makefile-based workflow as simple as possible. wasm/README.md is the most useful file to read.

As an example of the local deployments, the following video shows them working after running:

cd wasm
micromamba create -f wasm-environment.yml
micromamba activate git2cpp-wasm
make
make serve

git2cpp.mp4

Note the video shows the git2cpp package coming from a local directory rather than from prefix.dev.

The JupyterLite deployment only differs from the cockle one in that it uses the JupyterLite shared filesystem, which can and has been the source of different behaviour so it is useful to have them both.

For the local testing:

(git2cpp-wasm) malus:wasm iant$ make test
make -C test test
# A pytest fixture ensures that `npm run serve` runs for the duration of the tests.
cd ../../test && GIT2CPP_TEST_WASM=1 pytest -v -rP test_git.py
============================= test session starts ==============================
platform darwin -- Python 3.14.0, pytest-8.4.2, pluggy-1.6.0 -- /Users/iant/micromamba/envs/git2cpp-wasm/bin/python3.14
cachedir: .pytest_cache
rootdir: /Users/iant/github/git2cpp
configfile: .pytest.ini
plugins: anyio-4.11.0, base-url-2.1.0, playwright-0.7.1
collecting ... collected 3 items

test_git.py::test_version[chromium--v] PASSED                            [ 33%]
test_git.py::test_error_on_unknown_option[chromium] PASSED               [ 66%]
test_git.py::test_version[chromium---version] PASSED                     [100%]

==================================== PASSES ====================================
============================== 3 passed in 2.24s ===============================

This is only testing test_git.py, but I will add more in time. The important difference here is the use of GIT2CPP_TEST_WASM environment variable which enables a different set of test fixtures to the normal pytest run.

The wasm build clones the recipe from emscripten-forge/recipes, modifies it to read the source code from the local directory, and builds it. The two deployments and the deployment used in the tests all use the built package. The testing using the pytest-playwright extension with monkey-patching in both python and typescript to send the commands to a cockle Shell in the browser and return the results in a format compatible with subprocess.run.

Work to do after this in separate PRs:

• Build and run wasm tests in CI. I don't think this should run on every PR as there is too much that can go wrong initially, so perhaps just using a github actions workflow_dispatch so that any maintainer can manually run it on any branch as required.
• Build and deploy in CI. Github pages is the simplest to use but is restricted to a single branch such as main.
• I need to do more monkey-patching in python and typescript so that we can run more of and eventually all of the test suite in wasm.

[ianthomas23]

I've rewritten the makefiles using cmake, so now the process to try this out locally is

cd wasm
micromamba create -f wasm-environment.yml
micromamba activate git2cpp-wasm
cmake .
make
make serve

as described in wasm/README.md.

I've kept the cmake files in the wasm directory and below as separate cmake projects so that the don't interfere with the real cmake project in the top-level directory.

I am using an in-source build as that works, switching to a separate build tree (cmake -Bbuild; cd build; make) results in various problems, some of which are I think due to rattler-build using cmake whilst we are running our own make build or whatever.

[ianthomas23]

Thanks @JohanMabille. Let's merge and I can iterate on increasing the number of tests covered by the WebAssembly test code.