Upload Wheels and Per-platform PEXs to the Github Release

[thejcannon]

This change does a few things:

• Tweaks the release action to create a new release and upload everything in dist/gh_upload to the release (in each wheel job)
• Tweaks release.py to do what we want for the new world
• Tweaks the docs to reflect the changes

Note that the only backwards-incompatible changes are we are no longer building one universal PEX, and instead building one per platform. We 're still uploading to S3, etc...

Tweaks the the release action

First, we change the release action to create the release, instead of a human doing it.

• If this is a real release, will set the title to the release tag, and if the version doesn't have any letters, tags as --prerelease (we weren't consistent about this previously)
• If this is a "dev release" (those which people request to have wheels built) the title will be dev_<SHA> and it will always be --prerelease

Tweaks to release.py

• The universal PEX command was removed, and the local PEX is the one-and-only option
• build-local-pex now takes a destination and optionally a --stable argument(s)
  • the dest is set to gh_uploads to make uploading easier
  • --stable is passed if this is a real release
• It now builds the local PEX, with the name tweaked to include the machine (e.g. x86_64)
• The pex is always named simply (e.g. pants.<VERSION>.pex) the wheels are unstable/stable versioned

Tweaks to docs

We get to remove all of step 4 🎉

Next steps

• Adjust scie-pants to use the uploaded PEXs and avoid PyPI altogether
• Adjust pants_requirements to use the uploaded wheels from the release, and avoid PyPI altogether
  • PR: Resolve pants_requirements from direct wheel links to GitHub Release assets #19432

Then,

• Stop uploading to S3?
• Stop uploading to PyPI?
• Rip out a bunch of release code?

Fixes #12397 (at least, the Pants side, we'd wanna update scie-pants)

[thejcannon]

So far I've got:

$ rm -rf dist/gh_upload/
$ pants run src/python/pants_release/release.py -- build-local-pex --dest dist/gh_upload
josh@cephandrius:~/work/pants$ NO_SCIE_WARNING=1 ./dist/gh_upload/pants.cp39-linux_x86_64.pex --pants-config-files=[] --version
2.18.0.dev2+202306261651.git073c224f

$ rm -rf dist/gh_upload/
$ pants run src/python/pants_release/release.py -- build-local-pex --dest dist/gh_upload --stable
$ NO_SCIE_WARNING=1 ./dist/gh_upload/pants.cp39-linux_x86_64.pex --pants-config-files=[] --version
2.18.0.dev2

ls the directory (after removing wheels) gives me the pex and both pantsbuild wheels.

[thejcannon]

I tested this locally using act

[thejcannon]

The job and step got renamed to be more accurate.

[thejcannon]

Re-reading #19028 gives this quote from @stuhood

A PEX lockfile is effectively equivalent to a PEX. And so I think that if scie-pants were to begin consuming a released PEX lockfile to build venvs?

So alternatively, we could just publish the lockfile and not the PEX itself. It's hard to weigh all the pros/cons, realistically.

Also, I'm wondering if we continue to not use the PEX, and instead the published wheel from scie-pants? E.g. the find-links uses the release page.

That would be completely sufficient if we did #19282

So, maybe we adjust the PR to just upload the wheels to GitHub, and the rest still follows and we avoid building PEXs at all?

[thejcannon]

....And while I think about it, another thing to consider is backporting. We can easily download wheels from S3 or PyPI and upload those to earlier releases.

And (and I'm not sure I'm proposing this, I'm just documenting) if we stopped supporting PANTS_SHA (even for older releases) we could shut down per-sha wheel hosting on binaries.pantsbuild.org)

[thejcannon]

OK I'm splitting this PR into several smaller ones