Safer tweaking API #1017

We should have "safer" tweak functions that do the hashing automatically and include the inner point in the hash. See #1015

These would be BIP341-specifiek tweaking functions then that take the merkle_root as input? I believe that's sufficient to make the construction safe.

If we had a way to have callers provide their own SHA512 functions to a context, we could also add BIP32-specific tweak functions (or if we had SHA512 hashing to the library, which feels like scope creep, but I'm also not strongly against it).

What I had in mind were rather "generic" tweak functions that for example take tag, tweak, and pk and then output pk + SHA256(tag || pk || tweak). This are safe because pk is included and my hope was that this should cover all current uses because tag and tweak are simply prefixes and suffixes to pk. But I don't think it's that simple, BIP341 hashes xonly keys and I guess some other applications hash the 33-byte pk. We could still have tweak and xonly_tweak functions, we'll need them anyway.

And then we could provide convenience wrappers, e.g., for BIP341.

Unfortunately BIP32 needs a different interface because HMAC-SHA512 is not a hash function but takes two inputs... We could have an abstract H(tag, pk, tweak) with implementations H(tag, pk, tweak) = SHA256(tag || pk || tweak) and H(tag, pk, tweak) = HMAC-SHA512(tag, pk || tweak).

I don't know. If all of this is too complex in an API, we could still implement it this way under the hood.