Enable grouped Dependabot version updates for Rust

This enables Dependabot 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 a fork: EliahKagan#18

Author: EliahKagan

.github/dependabot.yml

@@ -1,15 +1,9 @@
 version: 2
 updates:
-  # Only GitHub Actions dependencies receive Dependabot *version* updates. Rust dependencies are
-  # checked via `cargo deny` (https://github.com/GitoxideLabs/gitoxide/issues/144) and updated
-  # manually or via Dependabot *security* updates (which the restrictions here do not constrain).
   - package-ecosystem: cargo
     directory: '/'
     schedule:
-      # We include this required key, but it only applies to version updates, which are suppressed.
       interval: monthly
-    # Disable version updates for Rust dependencies. Security updates are still allowed.
-    open-pull-requests-limit: 0
     commit-message:
       # Avoid non-"purposeful" prefix due to Dependabot misdetecting style (see `DEVELOPMENT.md`).
       prefix: ''