Cargo.toml: update crypto-mac to 0.10.0

[PaulGrandperrin]

This is an API breaking change

[oconnor663]

I've gone back and forth in the past about how properly to update digest and crypto-mac in the past:

• Bump digest crypto-mac #90
• Backwards incompatible changes in Blake3 0.3.5 #122

We're thinking about tagging this crate 1.0 any day now, so this is going to become more important. I don't think anyone wants to bump the crate to 2.0 when crypto-mac gets to 0.11. What's the right arrangement here? @tarcieri?

[tarcieri]

@oconnor663 in the signature crate (which is post-1.0) we've opted to have a set of "unstable features" with *-preview names which depend on the pre-1.0 RustCrypto trait crates (e.g. digest):

https://docs.rs/signature/1.3.0/signature/#unstable-features

We explicitly call these out-of-scope for semver, but have a policy that we bump the minor version when the trait crates are updated.

It's sort of similar to having a 0.x crate for these features, but the other parts of the API are covered under a "1.0" semver guarantee.

[tarcieri]

Also note: we'll be releasing crypto-mac to v0.11 sometime in the next few weeks. See:

RustCrypto/traits#392

[oconnor663]

The follow-up commit 07b746b implements @tarcieri's suggestion, similar to the digest crate. (Though I don't think we'll make the nuanced guarantee about patch vs minor version bumps.)

[tarcieri]

Hopefully we'll be able to get to 1.0 sometime this year. Depends how quickly const generics evolve (we don't want to ship a 1.0 with generic-array)