Add BIP 352 bindings (full node scanning only)

[nymius]

This PR adds a silentpayments module based on bitcoin-core/secp256k1#1765.

I've agreed with @jlest01 on opening this PR replacing the old #721.

Commit 7888c66 contains all the changes from bitcoin-core/secp256k1#1765. I'm referencing my own version of the branch to be free of rebasing it in the future. These commits should refer back to master branch once bitcoin-core/secp256k1#1765 is merged.

049e07f is a workaround for a compilation issue I had. I cannot provide a confident answer about the reasons, but the old configuration was breaking the symbols of the library making linking impossible.

Commit 1889342 to 776653d contain all the main changes related to the BIP 352 module.

I've collected the feedback from #721 and applied it in this PR.

Beside the changes related to changes in bitcoin-core/secp256k1#1765 or the feedback provided in #721, I included the following:

• Scoped sender and recipient logic in independent modules.
• Scoped silentpayments in its own module in secp256k1-sys.
• Adapted docs from libsecp256k1 PR, and added extra notes depending of the case.
• Added a feature gate for silentpayments.
• Transformed the original example into an integration test, as it is deterministic.
• Based the changes on the latest rust-secp256k1 master, so this PR uses a global secp context.

I changed the old #721 manually implemented cache for a rust-like one, using HashMaps. Now, thanks to the suggestion of @antonilol, you can pass a rust closure to the bindings, avoiding the implementation of unsafe extern C code.

Note to the reviewers:
After looking at the different context related issues (#813), and mainly #844 (comment), I decided to apply this re-randomization step only where I had secrets related to UTXO unlocking. For context: in BIP 352 you have the scanning secret key, which is not directly associated with UTXO unlocking, that's what the spending key is for.
So I decided to implement something similar to musig::new_nonce_pair for silentpayments::sender::create_outputs, using the combination of secret as random seed.
On the contrary, I didn't implement randomization for silentpayments::sender::scan_outputs for the reason explained above.
I would like to know if the criteria applied here is correct or not.

To execute the test:

cargo test --features="silentpayments" -- full_silentpayment_flow_one_sender_two_receivers

To execute the example:

cargo run --example silentpayments --features="rand silentpayments"