Improve the process to apply infra fixes from `microsoft/main` onto release branches

As of writing (starting to add release branch infra: https://github.com/microsoft/go/issues/128), it seems that the most reasonable way to apply infra fixes from microsoft/main onto release branches is cherry-picking. A few ideas to improve that process:

Automate the cherry-picks.

• This can be done with a GitHub Action with a comment trigger like dotnet/runtime's.
• We could create a bot that automatically cherry-picks PRs (based on a tag?) onto each currently maintained release branch to make it harder to forget, and potentially batch changes.

Periodically copy all build infra files from microsoft/main to all release branches.

• It seems like there would be significant maintenance overhead and risk involved with making a single version of the infra files always work on every single branch all the time. We should try to be sure that it's actually worthwhile before going with this approach rather than cherry-picking.

Make "fake" merges that carry infrastructure changes but ignore changes from the upstream commits.

• This provides a hint baked into Git about the last time changes were merged across. You can merge again and only merge "new" commits. However:
  • Merging doesn't distinguish upstream and Microsoft-infra commits. You need to essentially cherry-pick the infra commits to create the new "fake" merge commit.
  • Which way(s) should merges flow? This is part of determining how difficult the system will be to maintain.
  • What if the release branch intentionally has slightly different infra? Does this cause a lot of unnecessary merge conflicts?
• I'm including this option for completeness--I don't see net benefits to this approach vs. others. It's possible I'm missing some reasons it could help, though.

Start by reviewing issue #128 and the referenced dotnet/runtime backport.yml workflow to compare approaches for applying infrastructure fixes across release branches. Evaluate cherry-picking, periodic copying, and fake merges, then document or implement a selected process with clear branch coverage and maintenance expectations.