Enable Dependabot version updates for Rust

[EliahKagan]

This enables grouped Dependabot version updates for Rust (cargo) dependencies. Previously, only GitHub Actions dependencies were updated with Dependabot in this repository; see ed59e97 (#43).

The updates are grouped. So there is one one Dependabot version update PR for Rust dependencies per month, unless:

• The Dependabot update check is manually triggered, or
• dependabot.yml is changed (any change reruns update checks).

Because Dependabot security updates are enabled, pull requests shall still be opened for those, immediately when an advisory enters the GHSA database, provided that Dependabot is actually able to create the update. (Dependabot security updates are separate from Dependabot version updates.)

Caveat

A possible reason not to enable Dependabot version updates is if the tests are not robust enough to most likely detect regressions arising from dependency changes. I am not knowledgeable enough about cargo-smart-release to know if that could be a problem here.

You have sometimes mentioned that the tests here would need expansion in order to facilitate the introduction of some new features, such as a feature to handle circular dependency relationships (discussed in GitoxideLabs/gitoxide#1510 and GitoxideLabs/gitoxide#1886).

However, my guess is that the tests as they currently stand might still be enough, taken together with reading changelogs, to catch most regressions that arise due to updating dependencies.

Integration considerations

This does not fix issue #50. For that, I have opened #51, in which I've updated all lockfile dependencies to their latest compatible versions. I recommend merging #51 before merging this PR, so that the first Dependabot version update PR better resembles what it would look like once actually in shape to be merged.

(If you don't want Dependabot version updates, then I recommend merging #51 and closing this PR unmerged.)

If this PR were merged before #51, it's not really a problem, but we would still probably want to fix issue #50 before merging a Dependabot version update PR that doesn't fix it, so things would be slightly more complicated and slightly more confusing.

[Byron]

Thank you, I really appreciate you setting up the repositories for a greatly improved security posture.

You have sometimes mentioned that the tests here would need expansion in order to facilitate the introduction of some new features, such as a feature to handle circular dependency relationships (discussed in GitoxideLabs/gitoxide#1510 and GitoxideLabs/gitoxide#1886).

Indeed, but I'd also trust that dependency updates will be not ever be subtle enough to break the application unnoticed.
Besides that, it's true that ideally one will be able to setup better testing so the code is less brittle in the face of changes - changes that sometimes are necessary.
Right now I found myself trying certain PRs by using a custom build when trying to publish gitoxide, and if it worked it meant the PR could be merged. Of course, that workflow presents a serious bottleneck. Ideally, one could automate this and publish the actual gitoxide project to a local crates.io server instead. If that was possible, one could easily test any change and probably quite quickly iterate towards new features, without fear of regression.