protocol: Update hashes to 0.16.0

[rustaceanrob]

The hashes dependency made hex-conservative optional. With the likely removal of hashes from secp256k1, we can choose what hashes version we would like without duplicates.

[nyonson]

Hm, I am not sure on this one, but wanna make sure I understand the trade-offs. Bumping hashes to 0.16.0 makes the indirect hex-conservative dependency optional. And at least bip324 itself doesn't pull it in since it doesn't use the serde feature of hashes (possible that something else in a caller's dep tree flips that on). However, this does constrain the versions of hashes callers of bip324 can use. I believe we want this library to be as flexible as possible, so I'd like to err on the side of a wider dependency range. The caller can always choose to bump hashes themselves to clean up the deps. Does this make sense? Or am I missing an aspect here.

[rustaceanrob]

In that case I think we would need ^0.15.0 or however that syntax works. Currently the crate builds with 0.15.0 regardless of what the user does.

[nyonson]

Oh yea, I forgot how pre-major-version-1, 1.0.0, rules are different. Each minor version is a "breaking change", not just major. So right now we have 0.15.0, which is implicitly ^0.15.0, only patch upgrades are allowed. We could go more explicit like bitcoin_hashes = ">=0.15.0, <1.0.0", probably do-able with the hashes api being relatively small. Although, I'll check out what the rest of the ecosystem is doing to handle this.

[rustaceanrob]

Because 0.16.0 just removed hex, I think the safe bet is >=0.15.0, <0.17.0 and we check for breaks in 0.17.0

[rustaceanrob]

7ce1e98 changed to ranged version

[nyonson]

ACK 7ce1e98