Commit Cargo.lock to make CI and local debugging more stable

[faern]

The official recommendation regarding libraries commiting the cargo lockfile changed a while back: https://blog.rust-lang.org/2023/08/29/committing-lockfiles/. Previously libraries were not recommended to commit the lockfile. Now it's left up to the library maintainers to decide what fits their needs the best. For example cargo new --lib no longer ignores Cargo.lock by default.

I personally have found that always commiting the lockfile, even for libraries, provide for a much more reproducible debugging experience. Without a lockfile, every CI run might run with different dependencies. And local development becomes against whatever that developer has in their lockfile, instead of some shared view of the expected dependency tree.

Commiting a lockfile does not mean that's the only exact version of everything that the library support. The version range specified in Cargo.toml is still what dictates what versions the library should work with. But just having a stable reference to run against is sooo helpful.

For example now, when I submitted #854. The CI failed with this error that is completely unrelated to my PR: https://github.com/bheisler/criterion.rs/actions/runs/15076547284/job/42385189894?pr=854. The error is because if you get the latest version of all packages we depend on, some of them do not build against the version of rustc that criterion has specified as its MSRV.

Most crates do not treat MSRV changes as breaking changes (that's a completely correct IMHO), but it does create the issue that a dependency you have can suddenly require a newer rustc than you have specified that your library needs, but still be semver compatible with what you have specified. Then a commited lockfile stops the CI form randomly pulling in too new versions of that dependency.