Reversible vtxo in async payment

[louisinger]

This PR adds the necessary abstraction to process different types of VTXOs. It allows adding the ReversibleVtxoScript type used as output of async payments.

Vtxo script type

• A vtxo script is defined as a taproot contract with at least 1 forfeit closure (User && ASP) and 1 exit closure (A after t). It may contain others closures implementing specific use cases.
• common.VtxoScript abstracts the taproot complexity of vtxo script.
• a vtxo script is compiled, transferred and parsed using descriptor string.
• the default vtxo script is tr(_,{ and(pk(USER), pk(ASP)), and(older(T), pk(USER)) })
• the reversible vtxo script is tr(_,{ { and(pk(SENDER), pk(ASP)), and(older(T), pk(SENDER)) }, { and(pk(RECEIVER), pk(ASP) } })
• while spending a VTXO, the spender must provide the associated descriptor and the signer public key (in order to signal to the ASP the forfeit leaf to use)

TL;DR

• [common] add VtxoScript interface
• [tx-builder] use VtxoScript to craft vtxo tree transactions
• [api-spec] add descriptor instead of pubkey while registering inputs
• [api-spec] add signingPubKey when spending a VTXO
• [api-spec] specify descriptor instead of offchain address while registering outputs
• [db] replace Vtxo.Pubkey by Vtxo.Descriptor

PS: This PR does not add the necessary change to support the "Reverse" UX in the SDK even if it's technically possible today for the sender to spend (via reverse forfeit leaf) an async payment VTXO. It may need extra work to keep track of the reversible VTXOs and coin-select them.

@altafan @tiero @sekulicd @bordalix please review

[tiero]

May be worth to lay down the ground work of key path spending for cooperative cases? We may not need to migrate right now, but at least figuring out the abstraction of needs some more work in the future, better now