Implement getsharedsecret

[ZmnSCPxj]

Closes #3486

Alternate solution, where we use the exact same Lightning BOLT standard of hashing the point and returning that from hsmd.

I strongly disagree with this approach:

• If multiplying a secret scalar by an arbitrary SECP256K1 point and publicly revealing the resulting product risked revealing the secret scalar, then we should remember that the generator point G itself is an arbitrary SECP256K1 point (equal to 1 * G i.e. having a "secret" scalar of 1) and public-private cryptography would not be secure in the first place.
• We can implement getsharedsecret in terms of getecdh (Implement getecdh #3486) but not vice versa. With getecdh exposed we can implement using ECIES and the Lightning BOLT (Bitcoin-ish?) ECDH key agreement standards, with only getsharedsecret like this we can only implement the Lightning BOLT key agreement and we would need to implement something else in hsmd if we want to support ECIES and other EC encryption standards as well (Lightning BOLT seems the only one that does not use X-coordinate-of-ECDH-product). I strongly prefer to keep the interface of hsmd small to facilitate fully implementing it in an actual hardware module.

[rustyrussell]

ECIES is kind of a broken "standard" right now (with differences in implementation leading to incompatibilities), and anyway we'd be using a totally weird EC curve. Best practice also seems to be https://link.springer.com/article/10.1007/s10623-019-00685-y?wt_mc=alerts.TOCjournals&utm_source=toc&utm_medium=email&utm_campaign=toc_10623_88_2 to hash the ECDH output.

Given the issues in ECIES interop, I'd really prefer a secp256k1 implementation we can all use, given their expertise in these matters.

[ZmnSCPxj]

This uses the default ECDH behavior of libsecp256k1, which is what is used consistently elsewhere in Lightning.

[rustyrussell]

Ack a088425

[rustyrussell]

Trivial rebase...