feat(git-node): add support for promoting several releases at once

[aduh95]

And from a different remote. Currently, the git node release --promote workflow doesn't work well for security releases as it assumes the release proposal exists on the same repo as where we want to make the release, and releases are to be released one-by-one.
This PR aims at addressing all this shortcomings.

The process is now roughly:

1. for each proposal PR:
   1. Verify if it's ready (correct date, changelog entry, etc.).
   2. Create a signed tag for it.
   3. create a Working on … commit.
   4. rebase the public staging branch.
2. checkout the default branch, and cherry-pick all releases commit on top of it.
3. Print out a single git push command to push everything at once to the public repo.
4. Rest of the workflow is not affected.

I've tested this with 24.1.0 and 22.16.0, seems to work fine!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.76%. Comparing base (197134f) to head (b19f363).
Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #935   +/-   ##
=======================================
  Coverage   79.76%   79.76%           
=======================================
  Files          39       39           
  Lines        4630     4630           
=======================================
  Hits         3693     3693           
  Misses        937      937           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RafaelGSS]

So, it assumes a single releaser for the entire security release process. Although it might be the current situation, it wasn't like that in the past - I'm doing it because I'm paid to do this work, but in normal circumstances, it is expected to have one releaser per release proposal. So either the documentation must be clarified, or we should add an opt-in flag to promote several releases at once.

[aduh95]

or we should add an opt-in flag to promote several releases at once.

It is opt-in, you have to provide the URLs of the release proposal PR(s) you want to promote

it assumes a single releaser for the entire security release process

It does not, what it does is simplifying the workflow of promoting several releases at once, and the workflow of promoting one (or more) proposal that's hosted on a different repo (not related to this PR, but maybe worth discussing: IMO we should aim on having all the security releases being promoted at once, it's less work overall for the team, and it makes the time window between the time the fix is disclosed and the time it is available smaller, which is good to have).

[RafaelGSS]

what we do normally (when more than one releaser) is to push all the proposals to private branch first, so we merge the proposal to vN.x and vN.x-staging, and once all releasers complete that, we push it to public. It reduces even more the "risk-time".

[aduh95]

IIUC this PR does exactly that, using the local clone as the private repo, so the releaser can push all proposals at once.

[RafaelGSS]

Just make sure to update the https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#11-tag-and-sign-the-release-commit to mention it accepts a list of PRs to we won't forget that.

LGTM.