Fall back to isolated mode for metadata build & simplify codepath

[CAM-Gerlach]

Currently, as discussed in #78 (comment) , Pyroma still requires the user's build backend and any other required build deps to be installed in the same env Pyroma itself is installed in order to work. To work around this, we can have build fall back to using an isolated build environment with the project's build-system.requires build dependencies automatically installed, which will work with any build backend (including legacy setup.py builds, as it installs Setuptools by default if no pyproject build system is specified).

This retains the efficiency and (in some cases) backward compatibility of the existing non-isolated approach (if users have their backend already installed in the env Pyroma is installed), while now working reliably for any PEP 517 backend without users having to manually install their build dependencies. Both code paths are exercised in the test suite, as it contains test projects with both installed (Setuptools) and not-installed (Flit) build backends.

Additionally, this takes advantage of using the newer (Build 0.7.0) helper function build.util.project_wheel_metadata, which simplifies the metadata build code down to a single line, and makes it more efficient and reliable in the process, running virtually instantly in non-isolated envs.

Finally, I've updated the setup.cfg runtime and test dependencies accordingly, as well as added a python_requires and updated the trove classifiers to reflect the currently supported minimum Python version.

EDIT: Also, as discussed in hugovk@26dd7cd#commitcomment-91750223 , I've avoided the need to tightly constrain setuptools at runtime, and instead added a simple graceful fallback

EDIT 2: And as discussed in #72 (comment) , removed the accidentally-added pytest* test extra dependencies as well as the outdated fetch_classifiers MANIFEST exclude.

EDIT 3: Also removed wheel as a required dependency, as it is not directly required by pyroma (and instead required if needed by build and setuptools, as an implementation detail), while adding packaging, since it is used directly but was never added as an explicit dependency (but just merely happens to be satisfied transitively).

EDIT 4: Fix test failures with Setuptools >66.0.0 due to invalid versions making packages unbuildable (see #95)

Fix #64
Fix #95

[CAM-Gerlach]

Turns out using the new project_wheel_metadata helper, which sets the payload as the description by default, exposed a bug from back in the original implementation—data was only bound if the description was not present as a header, and was instead part of the payload.

[regebro]

This looks good to me, although I think something should be added to the CHANGES.txt file as well.

[CAM-Gerlach]

Sure, I went ahead and added that @regebro

[CAM-Gerlach]

Is there a plan to cut a 4.2 release with this soon, since it fixes several significant outstanding issues?