use lockfile rather than ad-hoc cargo update calls to pin dependencies

Aside from not being future-proof at all, it's actually extremely hard
to pin dependencies for this version of the library to get ones that work
with 9.x. We have an ancient version of `bitcoind` in our deps, which in
turn unconditionally depends on several crates which all have bad
behavior (at least, the versions that we depend on).

For example, both `zip` many versions and `bitcoind` itself have maximum
`flate2` versions which are incompatible with each other. The latest
version of `zip` 0.5.x removes the max version, but has an incorrectly
stated minimum version of `thiserror`, which manifests in compilation
errors because some trait impls aren't created by the `thiserror` macro.
(And of course, you can't just use the latest `thiserror` because that
does not compile with 1.41.1 for many reasons.)

This is just one example. There are probably 10 such cases.

Anyway now we have a lockfile and we can just forget about all this crap
forever.

As a secondary change: change all the `deny`s in lib.rs, except the one
about unsafe code which seems likely to be future-proof, to `warn`s. The
library doesn't compile on nightly otherwise, since e.g. the definition
of `dead_code` has expanded.

On my system I can now compile the library with both 1.41.1 and nightly
2025-06-23, with the same lockfile.

Author: apoelstra