Support building from `sdist` in a build action

Support building from `sdist` as a build action instead of `repository_rule`.

Things needed:
* [ ] A way to use a different `repository` rule that would not do any building with `pip`.
* [ ] Parsing the dependencies from `pyproject.toml` so that the `deps` field is populated at the repository time.
* [ ] A `pip` toolchain or something similar for building packages. Maybe we should have a `toolchain` for each build backend in the https://peps.python.org/pep-0621/
* [ ] A way to specify build dependencies see #1325.
* [ ] How do we build Python extensions?

Initial thoughts:
* It would be good to create an `sdist_archive` rule, which would download a given `sdist` by URL and then would parse `pyproject.toml`. If the `pyproject.toml` is not found or it is dynamic and requires Python to correctly infer the dependencies, we may need to fail at least in the first iteration.
* Using Python in the repository context is OK, but adds a lot of complication in the long run - we should attempt to limit its usage as much as possible.

At the moment I don't have time to work on this myself, but writing it down so that an issue for PEP621 based sdist building exists. Feel free to add thoughts here on possible design.

Überprüfe den bestehenden repository_rule- und build-action-Ablauf und untersuche anschließend, wie Abhängigkeiten in pyproject.toml behandelt werden. Verwende die vorgeschlagene sdist_archive-Regel und PEP 621 als Ausgangspunkte und kläre die Unterstützung für Build-Abhängigkeiten, Build-Backends und Python-Erweiterungen. Die Aufgabe ist erledigt, wenn der unterstützte Entwurf und der Implementierungsumfang vereinbart sind, statt als offene Fragen bestehen zu bleiben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.