Add nested MuSig

[jonasnick]

Nested (or "composable") MuSig is the idea of signing for a combined key that itself consists of combined keys. Ideally, it would not be possible for a signer to determine whether a peer is a single or a combined key. But we don't know how to do that securely at the moment (see @ZmnSCPxj's post for an analysis of the challenges). What we can do instead is a "Multi-R" (non-transparent) variant, where every individual signer in the MuSig reveals their nonce commitment and nonce. However, in that case most protocols could just have the signers agree to flatten their MuSig tree to depth one by revealing their individual keys to each other without adding additional complexity or privacy issues.

The following is how I would imagine it to work in libsecp-zkp. Step 1 and 2 would probably be the same for multi-R and transparent nested MuSig.

1. secp256k1_musig_pubkey_combine can be called multiple times with different pubkeys. For example, to get a combined key for A and (B and C), you'd first call pubkey_combine with pubkeys B and C and then use the result to call pubkey_combine with A. If you're a signer, you should use a different pre_session for each level to allow signing with the correct musig coefficient later. Additionally we should make sure that musig_pubkey_tweak_add also correctly works on the individual levels.

2. secp256k1_musig_session_init gets a new argument, n_layers. Instead of providing a single pre_session, you provide an array of n_layers-many pre_sessions. Instead of signers being an array to signers, it's an array of n_layers-many pointers to signers arrays. n_signers would be an array of size n_layers. Simlarly, my_index will also an array of n_layers. We can also provide a new init function to not make the existing function more complicated than it is already.

3. Every known signer presents a single nonce commitment as before. The difference is that a nonce commitment can either be opened with a nonce or with a list of more nonce commitments. For example, in a MuSig for (A and (B and C)), B and C exchange their nonce commitments hash(R_B) and hash(R_C). Then they combine their commitments into hash(hash(R_B), hash(R_C)) and send that to Alice. Later they reveal their tree of nonces R_B and R_C such that Alice can verify the commitment. The only changes for this code-wise is that set_nonce now gets a tree of nonce commitments and we need to decide how exactly to encode that. H/T to @roconnor for the tree commitment idea (also "If you do this, be sure to use tags so there is no ambiguity about whether you are hashing a nonce versus hashing a set of commitments.")