Improvement: extend automation of release cutting process

[pepopowitz]

Originally discussed in April, 2024 release retro.

The preferred practice when opening a PR for a new minor version is to open two PRs -- one unreviewable PR that contains the massive amount of content for the new version (unreviewable because it crashes your browser), and one reviewable PR that contains all the other smaller changes. Until now, I've been handling this with manually crafting commits based on their contents, often rebasing to re-sequence them so that the PRs can be opened and stacked properly.

These commits can be automated. We have a script that versions the docs, but it doesn't make any commits along the way. If we add git committing to the script, and commit things in a strategic order, this would make it easier for us to create two stacked PRs for the release.

See #3629 and #3630 for an example of how the stacked PRs are created.