chore: add automation for release keys

[nschonni]

Description

Either a test job in CI could run if someone touches the keys file, or a periodic sync can just check for changes and create a PR. I opted for the later, but the former would work as well.

Motivation and Context

#2569
I assume that a daily poll is more than frequent enough, although it's possible that a new Releaser could open the PR manually here while the other upstream PRs are waiting. Any sort issues would eventually get corrected by the PR this action would create.

Potentially the upstream documentation to open the PR here for the keys could be removed if this lands.

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[MikeMcC399]

I'm not sure if it should be part of the documented advice, but I would recommend disabling the workflow Automatically update Docker image versions before merging a PR with only key changes. That prevents immediate PR creation for a new Docker version release, and delays updating Dockerfile instances until there is an actual release using the changed key list.

[nschonni]

@MikeMcC399 I changed the cron frequency to weekly, and added a body parameter for the PR creation.
edit: First force push was missing the body, but fixed now

[MikeMcC399]

LGTM!