RGB payment workflow scenarious

@St333p is already working on this.

Since Sep 16, 2020.

## Scenarious
1. Bob is first-time user having no RGB (but having bitcoins)
2. Bob is first-time user having neither RGB nor bitcoins
3. Bob already has RGB tokens
4. Bob would like to receive LN payment with RGB tokens
5. Bob would like to receive RGB tokens non-interactively and/or recurrently

## Design criteria:
- Preserve as much privacy about pub keys, addresses and owned UTXOs as possible
- Reduce interactivity
- Prevent possibility of RGB assets loss b/c of non-intentious output spending with non-RGB-enabled wallets
- Support outputs with modified/tweaked keys
- UX simplification: reducing the friction for users to operate

## Scenario details
1. Onchain payment, Alice -> Bob; Bob is a bitcoiner, but first-time RGB user:
1.1. Bob derives new master subkeys at `m/82'/0'/...`
1.2a. Bob wallet generates an address with `m/82'/0'/0/N` encoded as normal bitcoin address
1.3a. Bob sends to this address bitcoin payment (also from some other wallet) from his other output
1.4a. Bob generates payment invoice with blinded newly-created UTXO
*-- if Bob do not need to keep privacy of his UTXO --*
1.2b. Bob creates PSBT spending to the new address
1.3b. Bob makes PSBT-based RGB invoice
1.4b. Alice does the payment; tx includes (a) Alice change, (b) Bob tokens, (c) single-use-seal witness
1.5b. If single-use-seal witness happens to Bob's token output Bob will get tweaking factor from PSBT sent alongside consignment
1.6. Alice sends consignment to Bob; Bob awaits transaction mining and merges consignment to his stash

2. Onchain payment, Alice -> Bob; Bob is new to bitcoin
2.1. Bob creates seed and derives a new master subkeys at `m/82'/0'/...`
2.2. Bob wallet generates an address with `m/82'/0'/0/N` encoded as normal bitcoin address
2.3. Bob sends miniscript-based RGB invoice
2.4. Alice creates transaction paying some satoshis to Bob's output
2.5. If single-use-seal witness happens to Bob's token output Bob will get tweaking factor from PSBT sent alongside consignment
2.6. Alice sends consignment to Bob; Bob awaits transaction mining and merges consignment to his stash

3. Onchain payment, Alice -> Bob; Bob already has RGB tokens
3.1. Bob creates UTXO-based invoice with blinded output, which scriptPubkey contains public key derived from `m/82'/0'/...`
... the rest is proceeded as usual ...

4. LN payment
4.1. Bob needs to ask Alice to establish a channel with him (Alice can be a payment hub/exchange)
4.2. (optionally) Bob computes route (normal LN process) to Alice providing her with routing hints
4.3. Bob generates LN RGB invoice - an extension to LN invoices with additional info on asset type
... payment proceed as usual for LN invoices ...

5. Bob needs to receive non-interactive, "anyone can pay" or repeated payments onchain (LN non-interactive and recurrent payments follow LN rules)
5.1. Bob derives a new master subkey branch under `m/82'/0'/...`
5.2. Bob shares his miniscript-based RGB invoice containing xpubkey information
5.3. Alice does recurrent or non-interactive payments, allocating some satoshis for Bob's outputs in witness transactions. Consignment with all required information are sent to Bitforst server provided by Bob as a part of the invoice

## Formats

### Invoices
* Blinded UTXO-based
* PSBT-based
* miniscript-based
* LN-based

### Data structures
* RGB-specific extended pub and private keys for mainnet, signet and different forms of scriptPubkey. Used in (a) wallet exports, (b) in PSBTs
* PSBT proprietary keys for:
- single-use-seal tweaks
- information on which key is tweaked
- blinding information on UTXOs (or pointers to the blind factors)
- xpubkeys in RGB format
- RGB amounts? (for simplification & double checking)