Modify Python requirements.txt in tests

[MakisH]

This PR fixes #584, allowing the Python-based tests to pick the correct, to-be-tested dependency versions in tests.

It replaces #745, which follows a different approach: In that PR, the aim is to install everything in a common venv, which runs into version conflicts and required changes in every component template and Docker build stage. The conflict manifests itself on the various Nutils-based tutorials, each depending on a different Nutils version, but it would also result in testing different setups than a user.

This PR takes into account that:

• now almost every tutorial has a requirements.txt
• our requirements.txt files seem to have rather loosely-restricted versions
• adding a concrete version from Git at the bottom of the requirements.txt seems to be preferred over the latest one from PyPI. I cannot find any documentation on this (most relevant: PEP 440 and PIP VCS support and dependency resolution), but I observe it consistently in my tests.

The approach I use is to add an a line with the corresponding _REF (e.g., git+https://github.com/precice/python-bindings.git@PYTHON_BINDINGS_REF) at the bottom of each requirements.txt file in the tutorial folder (to also include solver-python etc) that mentions the respective package (e.g., pyprecice). It looks like I don't need to remove the original line. This leads to, for example:

setuptools # required by nutils
nutils~=7.3
numpy >1, <2
pyprecice~=3.0
micro-manager-precice

git+https://github.com/precice/micro-manager.git@3ee74f81f0670c92433c5225520c989d4e931325

git+https://github.com/precice/python-bindings.git@f40889ab2d8d85560ef60cdaf7af2b6d694255b4

I am applying this step in the prepare: Docker Compose service template, which is where we also modify the precice-config.xml. This keeps the change minimal and applies it only once per tutorial. A downside is that every test builds the respective PIP packages (which does not seem to take long).

It substitutes the value passed as a Jinja2 template argument. I initially tried implementing it using the available environment variables, but this is simpler and does not require passing the build arguments as environment variables (which could also be misused at runtime).

I have tested the changes on the release test suite and previously in various attempts of this GHA test run (see attempts 36 + 43). I needed to increase the timeout of the previously untested two-scale-heat-conduction_macro-nutils_micro-nutils case and change its component in the metadata from nutils-adapter to micro-manager.

What remains open (but I will deal with in a separate PR) is:

• the FMI Runner does not yet have a component, so it also does not have an FMI_RUNNER_REF. The changes of this PR currently have no effect in the respective tests.
• the Nutils component is rather useless, since what it installs is always replaced. This is also the case in many cases that use the python-bindings (with the strange exception of the DuMux adapter component, which depends on the Micro-Manager, which depends on the Python bindings).