decouple cli from setuptools to allow new build backend integrations

[thrau]

Motivation

So far, the CLI has relied on setuptools and had setuptools in its indirect import path. To make plux work with other build backends, we need to abstract build-tool specific code from the CLI, and instead encapsulate it somewhere.

This PR introduces an abstraction, Project, over which the CLI is generalized. It's a bit of a kitchen-sink of factories right now, but I think it's decent enough to integrate new build backends.

The CLI now has a generic method _load_project, and each build tool has their own Project implementation that uses build-tool-specific APIs (such as locating packages, or information where the generated entry_points.txt lives in the context of the local distribution).

I also added a ton of inline code documentation.

Changes

• No functional changes, but significant refactoring of the CLI and the plux.build package
• Introduced Project as a concept

Future work

• plux.build.hatchling can now be implemented :-) in an initial step at least to a degree that the manual build mode works
• To test different build backends, we need to better isolate building and running plux in the test projects. Having both hatch and setuptools in the same project is not a good way to test both backends.
• Perhaps introducing a build backend config setting that allows us to do python -m build --config-setting plux-discover-plugins=True could be useful to do simplify python -m plux entrypoints && python -m build