Wheel build should use a locked requirements file

[jwnimmer-tri]

Is your feature request related to a problem? Please describe.

In our wheel build, currently we install some unpinned dependencies:

drake/tools/wheel/macos/build-wheel.sh

Lines 112 to 115 in 82999cb

	pip install --upgrade \
	delocate \
	setuptools \
	wheel

drake/tools/wheel/image/provision-python.sh

Lines 41 to 54 in 82999cb

	# TODO(jwnimmer-tri): Should these be version-pinned? What's the process for
	# keeping them up to date if they are?
	pip install \
	matplotlib \
	numpy \
	pyyaml \
	semantic-version \
	setuptools \
	wheel \
	auditwheel
	if [[ "$(uname)" == "Linux" ]]; then
	pip install patchelf
	fi

This is a problem because it means our wheel builds are not reproducible (so checking out a Drake tag and building it might produce a different result, or even not work at all), and that broken uploads to PyPI can break our Nightly CI out from under us.

Describe the solution you'd like

• Compute requirements lockfile(s) for our wheel builds, so that the versions of everything we need are consistent across repeated builds of the same Drake source tree.
• Ensure that the lockfile is regularly refreshed (ala Monthly upgrades for venv lockfile #22041).

Describe alternatives you've considered

n/a

Additional context

At the moment, in non-wheel builds, we only have venv lockfiles for macOS. This issue should lock both the Linux wheel build and the macOS wheel build, i.e., the two code snippets above.

This is a sub-task of the #8392 epic.

[jwnimmer-tri]

From f2f, implementation options:

(1) Run the jazzband lockfile generator a half dozen times (or whatever) on the matrix of python versions / platforms, to have N different lockfiles.

(2) Find a lockfile creation tool that can resolve dependencies in an interpreter and platform agnostic way, have just one lockfile.

(3) Just type in hard-coded numbers in https://github.com/RobotLocomotion/drake/blob/master/tools/wheel/image/provision-python.sh, without a lockfile, and without any automated re-locking tool

Doing option (2) would be best if we can find and wrangle such a tool. Otherwise we'll fall back to (3) and live with it indefinitely.

[mwoehlke-kitware]

PDM looks plausible for (2) (see also #22349), and if/when that lands, it shouldn't be a big deal to use it for the macOS wheels. However, having a separate implementation for the Linux wheels might be messy. IMHO, if we go in that direction, it would be best to tackle #22040 first, then locking for macOS wheels only, then switch Linux non-wheel builds over to using PDM for Python dependencies, and only lock the Linux wheel-build dependencies once PDM is already in place otherwise.