Add module "musig" that implements MuSig2 multi-signatures (BIP 327)

[jonasnick]

EDIT: based on #1518. Closes #1452. Most of the code is a copy from libsecp256k1-zkp. The API added in this PR is identical with the exception of two modifications:

1. I removed the unused scratch_space argument from secp256k1_musig_pubkey_agg. This argument was intended to allow using ecmult_multi algorithms for key aggregation in the future. But at this point it's unclear whether the scratch_space object will remain in its current form (see #1302).
2. Support for adaptor signatures was removed and therefore the adaptor argument of musig_nonce_process was also removed.

In contrast to the module in libsecp256k1-zkp, the module is non-experimental. I slightly cleaned up parts of the module, adjusted the code to the new definition of the VERIFY_CHECK macro and applied some simplifications that were possible because the module is now in the upstream repo (ge_from_bytes, ge_to_bytes). You can follow the changes I made to the libsecp256k1-zkp module at https://github.com/jonasnick/secp256k1-zkp/commits/musig2-upstream/.

[jonasnick]

Rebased on top of master to get https://github.com/bitcoin-core/secp256k1/pull/1480 which allowed dropping a commit. Old state is preserved at https://github.com/jonasnick/secp256k1/tree/musig2-module-backup.

[t-bast]

FWIW, we have JVM bindings on top of this branch in https://github.com/ACINQ/secp256k1-kmp/pull/93 and an implementation of swap-in-potentiam (musig2 key-path with alternative delayed script path) in https://github.com/ACINQ/bitcoin-kmp/pull/107 and everything is working fine, and the API is easy enough to use!

[jonasnick]

Rebased.

Thanks @t-bast, that's good to hear.

[siv2r]

Attaching a visualization for the API flow.

Edit: The above visualization is incorrect. I will update it with the correct one soon.

[jonasnick]

@josibake

What do you think about splitting out the sort commits into their own PR?

That's a good idea. In particular, if more fixups are needed for the sort commits. See #1518.