Currently we hard code python dependencies in the pre-commit config to
run mypy with the project's dependencies. This is obviously not ideal
from a maintainability point of view.

I did some investigation into improving this situation, and I've found
that we can run poetry from a python venv pre-commit manages and still
have it act on the poetry's own normal venv for the project dir. We can
do this by un-setting the VIRTUAL_ENV environment variable when running
poetry; this results in poetry ignoring the pre-commit venv it's
installed in, and instead using its normal project venv detection logic
to use the project dir's poetry venv.

As a result, if we use this method to install poetry dependencies via
poetry's pre-commit hook and use it to run the typecheck task from
pyproject.toml, poetry will run the mypy version from the poetry-managed
project venv (which is also the developer's own project venv when
running on a dev machine, which speeds up pre-commit hook runs an
reduces disk space usage).

This avoids the need to hardcode all the dependencies and versions, as
the pre-commit typecheck task will automatically use poetry's deps.

I've also changed the pre-commit CI job to run the post-checkout
pre-commit stage, because Poetry's install hook triggers on checkout,
not commit, and this isn't run in CI without this manual intervention.

mypy picks up python files under build/compose/tox at the moment. Version
1.16 includes an option to exclude everything in .gitignore, so we
enable that.

build: avoid hard-coding mypy deps in pre-commit

See merge request !47