Cargo.lock for hard pinning, Cargo.toml for pinning to non-breaking

[consideRatio]

With Cargo.lock describing exactly what versions to install and test with, I think it's good to let the Cargo.toml describe the broader constraints we have rather than do the same thing. So, I figure Cargo.toml would pin to the major version for example, and that we would have regular and automated updates of Cargo.lock, perhaps monthly.

This pattern has been a success for JupyterHub's Python and node based projects so far, offloading other PRs from thinking about these things and having us think about it as well - except that we typically shouldn't re-freeze the lock file ourselves unless there was a dependency added etc.

Practical changes proposed are:

1. Relax pinning of Cargo.toml files, from 1.2.3 to 1.* etc
2. Have Dependabot automation re-freeze the Cargo.lock files monthly with automated PR submissions, as configured via .github/dependabot.yaml

[consideRatio]

• Cargo.toml references version like 1.2.3, but it means ^1.2.3, which is equivalent to >=1.2.3,<2 (the first non-zero number is pinned), which is what I think we should have - so that was good.
• Cargo.lock is by default used. However, if Cargo.toml describes versions that doesn't work with the current Cargo.lock, it can get updated automatically unless --locked is passed. We should do that in CI systems (ci: make cargo use --locked, and avoid re-specifying shell: bash #195)
• We should preferably update the Cargo.lock file with automation, in my opinion no more than every month