Don't preinstall setuptools and wheel, remove from constraints

[joerick]

Reasons to do this:

• setuptools is no longer the only game in town. When cibuildwheel was created, setuptools was the only way to make wheels. these days, there are many build backends so special casing setuptools doesn't make so much sense
• we don't need to preinstall wheel any more, setuptools will do that itself when it needs it.
• projects with pyproject.toml (i.e. the vast majority of projects going forward) don't benefit from the pin anyway, because both pip and build create an isolated environment to install build-system.requires into.
• this makes it easier for end users (such as @webknjaz) to control build-system versions using PIP_CONSTRAINT, because there's less potential for a user-specified version to conflict with one of our pins.
  • (long-term, I'd love build to support this directly, and then we could have a proper way to keep pyproject.toml dependencies loose and forward-compatible while retaining build determinism. But PIP_CONSTRAINT is the best we have for now. PIP_CONSTRAINT isn't ideal because it affects other things, like the test virtualenv).

This PR also adds a pin for pypa/build. It appears that was missing before, but we should pin it.

[henryiii]

Would it make sense to get a release out before this? PyPy had a bug that broke NumPy's CI, and they had to pin on an older version, and we updated PyPy weeks ago, but haven't released yet. This seems like a bigger change that should sit in main a bit, but we are well past due on a a release with the latest PyPy.

[joerick]

This seems like a bigger change that should sit in main a bit, but we are well past due on a a release with the latest PyPy

Apologies, I missed the PyPy stuff over the holidays. I'll get a release out today/tomorrow.

[webknjaz]

@joerick since that release is out, should this be merged now?