Address upgrade friction during product releases

I went through our dependabot PRs this morning after releasing .NET 6. The .NET 6 product, and the various NuGet packages have all been upgraded. In this repo, and our other related repos, the upgrade actions created a number of friction points. I'm capturing those here. We have a year to consider how to address them:

- **Dependabot doesn't update the TFM**: None of our bots submit PRs to update the TFM (from `net5.0` to `net6.0`). As a result, many of the dependabot PRs didn't build. The dependabot PRs would (correctly) update an extension package from `5.x` to `6.0`. But, those updated extensions required the updated TFM.
- **Dependabot creates 1 PR for each project X package combination**: On major releases, this is more than 100 PRs. That's painful. We should be able to scope the PRs by folder / area. For instance, one PR for all updates to .NET Fundamentals, one PR for all ML.NET updates, one for all Azure SDK samples, etc.
- **Dependabot rebases on each PR merge**: This is related to the previous concern. Merging these PRs takes a long time, and uses extensive resources to do all the build actions on each rebase for all currently open Dependabot PRs.
- **Rate limits on GitHub resources**: Because of the previous point, we ran into some rate limits on PRs for other work.

I can think of a few ways to address these ideas.

- We could update the version sweeper to open PRs for new TFMs. (We've filed dependabot/dependabot-core#1953 with dependabot as well)
- We could build an action to approve + merge existing dependabot PRs.
- We could look for a different dependency manager, or consider creating one. There are a number of ideas / issues for dependabot on this [feature](https://github.com/dependabot/dependabot-core/issues?q=is%3Aissue+is%3Aopen+wildcards).
- Dependabot could address dependabot/dependabot-core#1190