dkg 2.0

[kayabaNerve]

The current dkg crate (or the one on the next branch) should be published as 1.0. That doesn't change it has flaws we should fix.

1. dkg shouldn't actually have any DKGs. It should just be the ThresholdKeys type. PedPoP should be moved to its own crate, as should Musig (which I did register the crates for). This would allow anyone to add their own DKG, such as Chill DKG.
2. Only having additive offsets/lagrange interpolation is insufficient. We should support multiplicative offsets, additive offsets, and either constant or lagrange interpolation (as seen with the dkg crate on the next branch). This was also noted in dkg/modular-frost 2.0 #195.
3. Replacing ThresholdKeys with BiasedKeyShare and UnbiasedKeyShare. This would allow higher-level protocols to specify which they need (Bitcoin needs a tweaked biased key or an unbiased key, Ethereum needs an unbiased key if the key is fed into keccak160 as addresses are).

Multiplicative offsets will be needed by the time Carrot comes around (the Monero FCMP++ hard fork) yet we shouldn't start working on this before Serai launches.

#195 was closed as it was cool things for a 2.0 yet nothing with concrete benefit. All of these do have concrete benefit, hence this issue existing now and standing.

[kayabaNerve]

Abstracted DKG's also may enable including obscure DKGs such as Monero's ECDH-premised DKG. I'm unsure it would in practice as Monero's DKG may not yield verification shares. While we could offer VerifiableBiasedKeyShare/VerifiableUnbiasedKeyShare (or rather Verifiable + Unbiased + KeyShare), I'm unsure we actually want to support algorithms without identifiable aborts.