Stop auto-merging periodic upstream sync in release branches

[dagood]

Right now, our sync infra is set up to submit PRs to the release branches that update the submodule to latest upstream commit in that branch every few days. These PRs have auto-merge enabled.

Upstream sometimes ports fixes into their release branches during the development cycle of the next patch release, and our sync process keeps up with it. The idea is that by proactively testing out ported changes that are planned to be part of the next release, we can fix up patches, infra, etc. before we run into issues on release day.

This can cause a problem:

1. Say the latest stable release is 1.18.1. Our submodule points at the go1.18.1 tag.
2. Upstream ports a few changes onto their release branch. The sync process creates a PR to bring them in.
3. Let's say the ported changes break some behavior that is only in our fork. We fix up our repo and merge the fixes at the same time we move the submodule forward.
4. Our submodule now points at go1.18.1+X commits (ports).
5. Uh oh: someone found a bug in our 1.18.1-1 build and we need to fix it and release 1.18.1-2!
6. To get the submodule back from go1.18.1+X to go1.18.1, we move it backwards.
7. We may need to revert the infra fix so that our build works without the ports from upstream. If we forget to revert something, it might change our build's behavior and introduce yet another problem that we need to fix.

We can remove the uncertainty by stopping syncing fix ports into our release branches. We would only update the release branches when either upstream makes a release or we need to release a new Microsoft revision. This way, the submodule only moves forward, rather than usually moving forward but sometimes moving backward.

We can still accomplish the goal of detecting upstream ports that break our builds by having the sync infrastructure create the update PRs, but simply not merge them. A notification system (#541) can let us know when there's a problem, and we can prepare a fix to apply when we eventually do move on to the next tagged release.

[dagood]

The title is effectively complete: the sync config only has EOL branches in it, so our active release branches don't have periodic sync infra set up. But I don't think this issue is complete: I do want to have something in place to continuously validate that the upstream release branch tips are compatible with our patches.