Modernize pystencils' dev environment

We should modernize the development environment of pystencils to latest Python practice. This includes:

pyproject.toml

We should migrate from the setup.py paradigm of setuptools to the now-standard pyproject.toml (PEP 518) for the basic build system configuration. This way, we can enjoy all the helpful tools that now base themselves on pyproject.toml (see 'Dependency Management' below). Still, some tool-specific stuff may have to remain in setup.py.

Dependency Management

Currently, as far as I am aware, setup of a dev environment for pystencils depends on requirements.txt files flying around wildly. To consolidate and clearly define a uniform development environment. we should instead introduce a packaging and dependency manager into the project - I'd recommend pdm. This way, all developers would get the exactly same environment, with exactly the same versions of all required dependencies - including dev and build dependencies like flake8, sphinx, etc.

Type Checking

pystencils has become a vast package with many moving parts, and as a generator of exectuable code, a high level of correctness is expected of it. While extensive unit tests are a necessary tool to achieve correctness, they can never be entirely watertight. Being written in Python, users and developers of pystencils enjoy great flexibility due to Python's dynamic type system. However, that same type system may also permit a much larger number of (potential) bugs to go unnoticed for a very long time.

To alleviate this issue, Python itself has been gradually introducing and improving its system of type hints, which although are not mandatory nor do they affect the code in any way by themselves. However, type checkers like mypy have been developed on top of that to statically check the types in Python code.

In particular in the context of #73, we should gradually introduce thorough static type checking into pystencils. This will help to make the code more robust and achieve a higher level of correctness a-priori. Types can be checked on developer's machines (e.g. as a hook to git add/git commit) and in the CI (much like linting with flake8).