This enables version updates for Rust dependencies, with all such updates grouped into a single PR, on a monthly cadence.

When Dependabot version updates for Rust dependencies (i.e. the cargo ecosystem) were turned off in 5f2d28e for #144, Dependabot did not yet support grouped version updates.

Clustering all the PRs to occur together once per month was possible, and it was considered and decided to be unsuitable, but that is different from a single PR to update multiple dependencies.

The comment #143 (reply in thread) noted:

...bundling its updates and making it once a month or even less often would be the preferred mode of operation.

Right now I would be hesitant to change the schedule interval in fear of an onslaught of PRs every month.

On the other hand, there may be value in seeing each PR as it contains release notes and changes...

Using grouped Dependabot version updates satisfies each of those points:

• The update PR can be set to occur once a month. (This is furthermore independent of the cadence for other ecosystems; it does not require that GitHub Actions version updates be only once a month.)
• It is a single PR for all updates in the cargo ecosystems, not an onslaught of multiple PRs, so long as it is configured with a single group with which the exhaustive pattern * is associated.
• The Dependabot pull request description includes any and all of release notes, changelogs, and commits since the release being upgraded from, for each of the dependencies being upgraded.

Because we already have Dependabot security updates enabled, which are created immediately for any security advisory where Dependabot can upgrade the dependency, it should not be a problem to configure Dependabot version updates on a monthly cadence.

This will include updates with breaking changes, so long as they're consistent with explicitly declared MSRV and other constraints. This shouldn't cause a problem, since CI is fairly robust, and will thus detect most breakages. When it is necessary to make changes to adapt to new versions, changes can be committed to the Dependabot feature branch for the PR (or other techniques can be used).

To see what the first Dependabot PR after these changes is likely to look like, as well as what kind of commits to its feature branch are likely to fix it up to be ready to merge, see this experiment in my fork: EliahKagan#18

The possible harm from this change is small, since the Dependabot grouped version update PRs must still be manually approved, and since this configuration can be customized, such as to ignore some dependencies or in various other ways, or even reverted.

I may request a review on the first Dependabot grouped version update PR resulting from this configuration, however. (Edit: I have done so in #1949.)