feat: update penumbra deps to v1 crates

[conorsch]

Opening early to discuss implementation options. Refs #30.

[cronokirby]

I think the overall approach we have in the current version of the draft is good.

I think for Block, we unfortunately do need to store the latest version, I think. The alternative would be just storing raw bytes, but I think we do end up needing to parse out the height, so we need to parse out those bytes as some versioned tendermint type.

For other types, I think we can get away with something more independent:

• For DeliverTx, we can just store the bytes of the transaction as a Vec.
• For EndBlock we can store the height, as a u64 or i64 (of the top of my head I forget which one is more prevalent throughout the crate).
• For Event, I think the common pattern would be something isomorphic to (String, Vec<(Vec<u8>, Vec<u8>, bool)>). (Eventually, it's assumed that these bytes are valid utf-8, but this assumption can turn its head when we actually convert it to the right versioned type).

Also, for juggling multiple versions, maybe what we should do is:

• inside tendermint_compat, have:
• mod v0o37
• mod v0o40
• the base module itself.

Then, each sub module would re-export the same types with the same name, importing from the same tendermint protos.

Then, it would be easy to see that if you have a function of type:

fn foo(x: tendermint_compat::DeliverTx) -> tendermint_compat::v0o37::DeliverTx

what's going on.

This scales to the inevitable time when we have more than two version as well, since we won't need to change anything.

[conorsch]

Pushed a rough draft of the compat types. Still doesn't compile, but the shape of the impls seems workable. There's too many unwraps for velocity: maybe it's worthwhile to update the Penumbra trait to return Results now, given the fallibility of the conversions.

[conorsch]

Beautiful! With the latest additions, I can run the archive integration tests to completion. This looks pretty well-shaped to me. As you mentioned in chat, there's likely some additional cleanup that's warranted here, but this looks overall sufficient to me that we can start working on #32 in parallel.