Switch to cargo-release for publishing crates

[conorsch]

Over in the Penumbra monorepo, we've started using cargo release (penumbra-zone/penumbra#2384) to trigger deployments based on tag pushes. In the ibc-types repo, we have a bespoke scripted implementation designed to work around ratelimiting for crates.io.

Based on upstream discussion crate-ci/cargo-release#483, I suspect we've rounded the corner on the ratelimiting issues, because we're now updating crates, rather than publishing brand new crates on the regular. Still, more testing is needed.

Let's try to get the tag -> build -> publish flow as simple and reliable as possible, to minimize the turnaround time between a PR from an external contributor and that new code landing in a published crate version. It'd also be nice-to-have if the workflow is similar to others we use elsewhere, to reduce friction when hopping between repos—thus the suggestion for standardizing on cargo-release.

[erwanor]

Using cargo-release would be a huge win. Another ad-hoc thing we are doing in the release script is upload the crates in a specific order and wait between each upload. We have to do this because some crates depend on one another. When publishing a crate, all its dependencies must be resolvable by crates.io. Since we version every crate in lockstep, this mean we must be careful about the order in which we upload them. What's more, there's some slight caching delay on crates.io's side between the moment the crate publication process finishes and when the crate's new version is actually observable. All of those things seem like things that could be taken care of by cargo-release.