Wrap the silentpayments module from libsecp256k1. This is placed in
common as it is intended to be used by:

  * RPCs: for parsing addresses
  * Wallet: for sending, receiving, spending silent payment outputs
  * Node: for creating silent payment indexes for light clients

Have `IsValidDestination` return false for silent payment destinations
and set an error string when decoding a silent payment address.

This prevents anyone from sending to a silent payment address before
sending is implemented in the wallet, but also allows the functions to
be used in the unit testing famework.

Use the test vectors to test sending and receiving. A few cases are not
covered here, namely anything that requires testing specific to the
wallet. For example:

* Taproot script path spending is not tested, as that is better tested in
  a wallets coin selection / signing logic
* Re-computing outputs during RBF is not tested, as that is better
  tested in a wallets RBF logic

The unit tests are written in such a way that adding new test cases is
as easy as updating the JSON file

BIP352 v0 specifies that a silent payment output is a taproot output.
Taproot scriptPubKeys are a fixed size, so when calculating the
serialized size for a CRecipient with a V0SilentPayments destination,
use WitnessV1Taproot for the serialized txout size.

Add a method for retreiving a private key for a given scriptPubKey.
If the scriptPubKey is a taproot output, tweak the private key with the
merkle root or hash of the public key, if applicable.

Add a flag to the `CoinControl` object if silent payment destinations
are provided. Before adding the flag, call a function which checks if:

* The wallet has private keys
* The wallet is unlocked

Without both of the above being true, we cannot send to a silent payment
address.

During coin selection, if this flag is set, skip taproot inputs when
script spend data is available. This is based on the assumption that if
a user provides script spend data, they don't have access to the key
path spend. As future improvement, we could instead check to see if we
have access to the key path spend, and only exclude the output when we
don't regardless of whether or not the user provides script spend data.

Also skip UTXOs of type `WITNESS_UNKNOWN`, although it is very unlikely
our wallet would ever try to spend a witness unknown output.

`CreateSilentPaymentsOutputs` gets the correct private keys, adds them
together, groups the silent payment destinations and then generates the
taproot script pubkeys. These are then passed back to
CreateTransactionInternal, which uses these scriptPubKeys to update
vecSend before adding them to the transaction outputs.

If sending to a silent payment destination, the change type should be taproot

This is a temporary measure and might not be what we want long term.

this is a temporary measure. The alternative to having this method is
to store the full spk + tweak in the DB (34 + 32 bytes), vs only storing
the tweak (32 bytes) and recreating the spks every time we load the tweaks.

Another option is to add this method directly to V0SilentPayments so that
its not generally available for any CPubKey.

* Exclude OutputType::SILENT_PAYMENT from wallet notifications fuzz test
  because wallet cannot create a V0SilentPaymentDestination yet

* Add base58 prefixes for Silent Payment Keys
* Encode and Decode SP Keys using Base58Check. This will changed to Bech32M later

This allows DescriptorImpl.Extract to add spkeys to
FlatSigningProvider

Parse sp(sppub or spprv) or sp(scan_priv_key,spend_pub_key or spend_priv_key)

Update GenerateWalletDescriptor to generate sp descriptor for SP and return scan and spend private keys to caller
Add function to extranct SP tweak data from tx and spent_coins
Add function to extract SpPubKey from an sp desc
All of these will be used for the SP DescriptorSPKMan Impl

Optionally allow users to create a wallet that supports silent payments.
This is signaled through an option in createwallet and a new wallet
flag.

Call IsMineSilentPayment when sending to a SP address if our wallet has
SPs enabled.

In `CreateSilentPaymentOutputs`, we create a change output using silent payments. The
presence of the change output will cause us to not fully check the
transaction and thus never create the silent payment tweaks, which is
why we check for self-transfers here. This feels a bit hacky, but works
for now.

* Allow same Silent Payments DSPKM to be loaded as both internal and external spkm
* Update AddWalletDescriptor to handle silent payment descr