musig: nested Multikeys

[oleganza]

Sometimes a party to a MuSig protocol may consist of multiple parties.

Making MuSig fully recursive and hiding presence of those sub-parties would likely require complicated rounds of proofs and aggregated signatures for the intermediate nonces, so we are going to start with a simpler API:

1. Every party is fine exposing the underlying pubkey to the other signing parties. (Note: if those are used with Keytree, all such keys will be the one-time child keys, so the privacy guarantee of Keytree is maintained.)
2. Multikey structure is instantiated not with a Vec<VerificationKey>, but with a Vec<impl Into<Multikey>>, which admits both list of plain keys and Multikey instances.
3. Each Signer* state keeps internally a list of underlying Signer* states for each key in a multikey. If the party has a plain key, it does not fall through to nested Parties.
4. Signer* API returns not a single commitment/precommitment/siglet, but a Vec of those. Leaf party would return Vec of one thing, while an intermediate Signer would accumulate all results from nested Parties and return the concatenation of their results.
5. Counterparty* API should similarly work with lists of things, not individual things. That means, from a perspective of each party, they would not have a flat list of all leaf counterparties, but only a list of intermediate (immediate) counterparties, but passing aggregated lists of precommitments/commitments/siglets into them. Flattening only happens when an intermediate Party aggregates results from underlying Parties and returns it to other signers.
6. Multikey::factor_for_key and/or SignerAwaitingCommitments::receive_commitments should recursively apply a multiplicative delinearization factor a_i from an upper level to a lower level, to appropriately reflect accumulation of such factors:

x  = Multikey(x0,x1)
x0 = Multikey(y0,y1)

x = a0·x0 + a1·x1
  = a0·(b0·y0 + b1·y1) + a1*x1
  = (a0·b0)·y0 + (a0·b1)·y1 + a1*x1

In the above example, for the x0=Multikey(y0,y1) the total multiplicative adjustment factor is a0.

Note: this multiplicative adjustment factor is completely independent from an additive adjustment factor for Keytree (#234) and both can be applied in a setting where keys are both blinded and consist of nested multikeys.