ci: Update release workflow

[samuelburnham]

This PR updates the release CI workflow to enhance automation and better align with the release process for downstream repos.

Release flow:

• The upstream sync workflow will check for the latest upstream Aptos PFN mainnet release, and if this version is newer than the latest local release, it will open an issue detailing how to release a new version.
• Then, the maintainer should hard reset origin/dev to the commit associated with the latest upstream release, cherry-pick the patch commits and CI changes previously on dev, and force-push to dev.
• Then, the release PR workflow can be manually run with the given version, which will PR a new release/aptos-node-<version>-patched branch to dev, which simply increments the version number in some metadata file e.g. PATCH_RELEASE.md (since this repo doesn't use Cargo versioning). The purpose of this is to 1. Create a minimal PR to solicit CI & review feedback, and 2. to create the release/* branch as a permanent artifact to be used as the source of the release.
• Once this PR is merged, the publish workflow is automatically triggered, which tags and releases the current release/ branch as a patched version of the upstream release. NOTE: Do not delete the release/ branch after it's been merged to dev, as it will be a load-bearing dependency for downstream crates and the base for future hotfixes.

Hotfix flow:

• Checkout a new branch off of release/aptos-node-<version>-patched called hotfix/aptos-node-<version>-patched.
• Commit and push changes to origin.
• Run the release PR workflow, but this time specify the hotfix input and the same version as before. This will create a PR containing both the hotfixes and the PATCH_RELEASE.md version bump, with the release/ branch of the same version as the base branch.
• When merged, the publish workflow will re-publish the release/ branch, overwriting the existing release. The hotfix/ branch can then be deleted as it is no longer needed.

Future work:

• Squash patch/CI changes into a single commit and store them on a patch branch or similar for ease of use (more notes at the end).
• Automate the dev force push if it's deemed sufficiently secure. The artifacts we want to keep are the release/* branches, as well as the patch commits somewhere that can be cherry-picked.
• Automatically open release PRs in each downstream crate when one is created here, which will make it easier to get CI feedback on bumping other crates. This is especially important for hotfix releases, which overwrite existing versions and could thus potentially break downstream crates if not carefully checked beforehand.

Note

Rebase/force-pushing to dev on every release is unusual, and mainly used here for consistency with our other release processes (merging release PRs into the default branch) and ease of use. We could instead rebase the dev patch commits on latest upstream, but this generated numerous merge conflicts with over 100 commits between releases.

We could instead keep dev as the patch branch and merge releases into a prod branch or similar, but then there's not much use for dev being the default branch since continuous development is not expected. Will explore this further.

Tested on https://github.com/samuelburnham/aptos-core

[tchataigner]

I think there is a typo to fix