The unit tests that are executed upon a push/PR are vital to ensure a successful continuous development of the code. This of course requires the same software environment to ensure realistic testing conditions.

Currently, each of the jobs in the github action workflow creates the software stack every time the job is executed. Since multiple jobs can share a software environment and the software stack itself doesn't change with every PR, this is not the most effective way to go about this.

This (draft) PR introduces the concept of caching part of the data for repeated use. It provides a very preliminary implementation with a lot of code repetition at the moment, but can be seen as a proof of concept already imho. Things that need to be investigated in the scope of this PR

•  try to avoid the copy-pasting of cache jobs -> composite jobs?
• try to bundle the software stack generation and caching into a reusable workflow that can then be used for each of the individual virtual environments

This PR has undergone a significant amount of changes during it's life time. @dsavoiu was kind enough to summarize the current set of changes - thanks again, and sorry that I didn't do this in the first place! It's much appreciated :)

For reference and to facilitate future reviews, let me summarize what I believe to be the main changes introduced by this PR (feel free to supplement this list in case I forgot anything and/or add this information to the PR description):

• move to pyproject.toml for specifying project metadata
• use unidep for managing both conda and pip dependencies in one place
• leverage setuptools to install dependencies for shipped venvs by specifying them as dynamic optional-requirements
• resolve pinned dependencies using uv pip-compile
• assign hashes to resolved set of pinned dependencies and leverage this for caching software environments in a CI/CD context
• provide a Dockerfile to construct a Docker container containing the entire software stack, including a user-defined selection of sandboxes
• refactor and expand GitHub Actions workflows to take advantage of the above features

Any suggestions are of course very welcome!