Add high-level helpers for using Musig2 with Taproot

[t-bast]

When using Musig2 for a taproot key path, we can provide simpler helper functions to collaboratively build a shared signature for the spending transaction.

This hides all of the low-level details of how the musig2 algorithm works, by exposing a subset of what can be done that is sufficient for spending taproot inputs.

[sstone]

This should be "rebased" on top of #107, which implements a musig2 API that is different than the current prototype on master and is based on ACINQ/secp256k1-kmp#93 which implements a low-level musig2 API that tracks what will be added to https://github.com/bitcoin-core/secp256k1/ and should not change much now.

[t-bast]

Nice, I'll do that!

[t-bast]

This should be "rebased" on top of #107, which implements a musig2 API that is different than the current prototype on master and is based on ACINQ/secp256k1-kmp#93 which implements a low-level musig2 API that tracks what will be added to https://github.com/bitcoin-core/secp256k1/ and should not change much now.

I started the rebase, but the exposed functions are quite inconvenient to work with, I suspect that #107 can be greatly improved. I'll review it thoroughly once the libsecp256k1 version is stable enough.

[sstone]

I started the rebase, but the exposed functions are quite inconvenient to work with, I suspect that #107 can be greatly improved. I'll review it thoroughly once the libsecp256k1 version is stable enough.

secp256k1-kmp is "dumb" and exposes secp256k1's API as directly as possible, if it's difficult to work with we may want to open issues upstream. In any case I'd rather keep secp256k1-kmp as simple as possible (from an integration p.o.v) and if needed provide better abstractions in this library instead.

[t-bast]

I agree that secp256k1-kmp should directly wrap secp256k1 without adding helper functions. But bitcoin-kmp should definitely add those helper functions to hide the secp256k1 API whenever possible!

[sstone]

Sorry I thought you meant ACINQ/secp256k1-kmp#93. I agree that #107 is pretty basic but it made building our new swap-in protocol simpler (because it's easier to see how musig2 is used).