Add App Token to release workflow so CI jobs run (#7324)

Adding an App Token to the release workflow so CI jobs run.

This App Token is currently stored as an actions secret. Actions prevents forks from reading secrets, so we'd have to explicitly merge a PR in order to leak the secret. Actions also redacts secrets, so we should be mostly safe from typos.

If we later decide we want to protect it further, we have two options:

1. Migrate it to a deployment secret for increased security. This way _any_ workflow run accessing the secret requires explicit approval from the maintainers. Unfortunately, the workflow will just hang in a "waiting" state, but not easily notify the user that it needs approval. I prototyped the workflow, and it was pretty clunky--we had to trigger the workflow, remember to manually approve it, and only then the PR shows up... vs we'd like to use the PR showing up every week automatically as a reminder to cut a release. Vs here the PR just shows up and waits for us to merge it, CI will already have run.
2. Migrate the entire workflow to a private repo. This way we reduce the odds of leaking the secret, but the workflows are a little complicated because a workflow in another repo can't trigger "on release". In other words, it'd be easy to migrate this "generate PR" workflow, but the secret we care more about is the RubyGems API key and that'd still be in the clear unless we migrated it. So we'd end up having to have a small trigger workflow in this repo that watches for releases, then triggers the workflow in the private repo.

Both of the above options are technically more secure, but it's primarily defense-in-depth as actions will already keep the current state secure unless we really screw up a PR review or fat-finger a major major typo. So after discussion we decided the inconvenience of the above two options aren't worth the increased defense-in-depth they provide.

We went with an application token rather than a PAT so that the token isn't tied to a particular developer's account. The app is scoped to only this specific repo, so if it's compromised it won't allow privilege escalation to other repos.

.github/workflows/gems-bump-version.yml

@@ -15,8 +15,16 @@ jobs:
   Create-PR-To-Bump-Dependabot-Gems-Version:
     runs-on: ubuntu-latest
     steps:
+      - name: Generate token
+        id: generate_token
+        uses: tibdex/github-app-token@b62528385c34dbc9f38e5f4225ac829252d1ea92 # v1.8.0
+        with:
+          app_id: ${{ secrets.DEPENDABOT_CORE_ACTION_AUTOMATION_APP_ID }}
+          private_key: ${{ secrets.DEPENDABOT_CORE_ACTION_AUTOMATION_PRIVATE_KEY }}
+
       - uses: actions/checkout@v3
         with:
+          token: ${{ steps.generate_token.outputs.token }}
           # Ensure we start from main in case the workflow is run from a branch
           ref: "main"
 
@@ -64,7 +72,7 @@ jobs:
           echo "PR created at URL: $PR_URL"
           echo "PR_URL=$PR_URL" >> $GITHUB_ENV
         env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GH_TOKEN: ${{ steps.generate_token.outputs.token }}
 
       - name: Set summary
         run: |