feat: implement p2p dkg + threshold signing

[avahowell]

This PR uses magic wormhole, which internally uses a PAKE (SPAKE2), in order to implement a mutually-authenticated+encrypted network layer for executing our implementation of FROST dkg and threshold signing. pcli generates magic wormhole tickets, which users then share out of band once (at the start of the DKG or signing session) in order to bootstrap authenticated connections.

[hdevalence]

This is sick!

I have a few high-level questions:

1. Is there a way to bootstrap the ticket selection off of the shared secrets already known to the participatnts, at least in the signing case?
2. Is it better for this to be a new backend, or should this be an option on the existing threshold backend?
3. Going forward, should we plan to refactor this code so that it's a communications protocol which might be instantiated using a terminal, rather than a terminal that happens to be networked? Like do we end up in our own version of "VT100 terminal emulation" forever?

[hdevalence]

Idea for improving the UX around ticket sharing: use BIP39 words.

DKG: In this case, there is not already a shared secret, so the coordinator can generate a 128 bit key and encode it into a 12 word "setup phrase". The CLI should instruct users to share it with their cosigners and inform users that it's only used for communication.

Signing: In this case, the signers already have a shared secret in the form of the FVK. We don't want that to be the only info needed to participate, but 2 BIP39 words might be sufficient (22 bits of interactive security among people who already have account visibility). What if the shared secret was H(fvk || 22 bits of secret)? Then we could have a UX where signers just need to know a temporary code like wormhole.

Can tickets be collapsed this way or do they have routing data that can't be derived like that?

[avahowell]

As of latest commit, this PR uses magic wormhole as a library to implement mutually authenticated channels. Since it uses a PAKE, in the form of SPAKE2, this should provide us with the best of both worlds: small, memorable, easy to transport tickets and an acceptable security level for ephemeral channels.

Is it better for this to be a new backend, or should this be an option on the existing threshold backend?

I created a new type on the Custody enum (https://github.com/penumbra-zone/penumbra/blob/refs/heads/iroh-threshold/crates/bin/pcli/src/config.rs#L75), but currently this just reuses the threshold config and the threshold backend. All of the new functionality is implemented inside the Terminal abstraction, using a new NetworkedTerminal impl.