Restructure packaging/ci infrastructure

[sdrave]

This PR contains a major overhaul of pyMOR's packaging an CI infrastructure.

Main packaging changes:

• pyproject.toml-based package with hatch(ling) as build backend.
• All (optional) dependencies are specified in pyproject.toml using extras. This includes additional dependencies for CI, etc.
• Dependency specification is completely static. dependencies.py is removed.
• versioneer is replaced in favor of statically setting the version in __init__.py, which is extracted by the buildsytem to determine the package version.
• All tool configuration is now in pyproject.toml. setup.cfg has been removed.

Main CI changes:

• We generate requirements-*-txt lock files from pyproject.toml using pip-compile.
  To update, call make ci_requirements.
• CI images are based on a single Dockerfile located in docker/. The Dockerfile installs the current locked requirements into the image. The pymor/docker is obsolete.
  To generate, call make ci_images. To push to the registry, call make ci_images_push.
• The tag of the CI image is the sha256sum of the used requirements file. The preflight phase in the gitlab pipeline computes this hash for the currently tested source tree. The following stages use this hash to select the CI image.
• ATM, we have ci-current, ci-oldest and ci-fenics. ci-current will have it's requirements and Python version periodically updated to follow upstream. ci-oldest will only be updated, when a new dependency is added or a minimal required version is bumped.
• Since Fenics is not pip-installable, we have an additional CI image, for it. In the future we might have additional images, e.g. for FenicsX. The general idea is to use some current 'official' docker image for external solver which are not available via pip and install pyMOR into that image.
• I have removed several CI jobs, in particular all installed tests and the binder-related stuff. (The binder links should still work.)
• Conda tests use an environment lock file generated from pyproject.toml using conda-lock, which works simliar to pip-compile.
• Hypothesis profile for conda tests has been set to dev to avoid build timeouts.

Remarks:

• We don't really need many features of the chosen build backend, but hatch seems to be popular these days. Also, we use its hatch-vcs plugin for version management.
• Neither requirements nor docker images are updated automatically right now. Regarding the requirements I plan to add a github action which warns to call make ci_dependencies if necessary. I am thinking about automating the image generation in the future in the CI pipeline. I would leave this for a future PR, however.
• Generating the requirements only uses docker to ensure that pip-comile runs with the right Python version. I have good experience with rootless podman (export DOCKER=podman).
• pip-compile will only bump versions when explicitly instructed to or required by a new dependency. Unfortunately, conda-lock will not lock at the current lock file and always use most recent versions.

[github-actions]

Please wait for #2016 to be merged before merging this PR.