LSPS1: Explicitly support LSPS1 payment options (#101)

* LSPS1: Explicitly support LSPS1 payment options

This PR aims to address a few problems in LSPS1.
I'll provide a few motivating examples of why I believe
the changes proposed in this MR are desirable.

# 1. Use seprate fee for onchain vs lightning payment

Onchain payments are more expensive for the LSP than lightning payments
because they create their own utxo. The LSP will have to carry the cost
of spending that new utxo at a later point in time.

This PR provides LSP's the option to set a different fee depending
on the payment method.

On a related note @2Fast2BCn [noted](#95 (comment))
that a similar argument could be made for the `expiry_date` of an order.
The LSP might want to set a different `expiry_date` depending on the
chosen payment option.

See issue: #92
See comment: #95 (comment)

# 2. Extensibility for additional payment methods

This PR allows to add additional payment options later.

In this section I'll provide a few motivating example.

## 2.1. Dual funding

Recently, dual-funding got merged to the spec. The spec describes a new
channel open protocol in which both the client and server can contribute
funds.

This approach provides a superior trust model. The client doesn't have
to trust the LSP to open the channel. The benefit is especially clear if
`client_balance_sat` is high. In the current version of LSPS1 the LSP
could take the money and run.

## 2.2. BOLT-12 support

Today, BOLT-11 invoices are commonly used to make payments over
lightning. Personally, I'd describe myself as a BOLT-12 maxi. This PR
makes it easier to add BOLT-12 as a payment option later.

### 2.3 Withhold from first payment

We see a demand for JIT-channels where the client specifies the
channel-size. This is currently not possible on LSPS2 or LSPS4.

See issue: #65

# Breaking changes: Why (not) to merge this MR?

We are in a bit of tension here. The spec is marked as
`FOR IMPLEMENTATION` but we are seeing some usage on mainnet.

This PR is breaking in the sense that clients will not be able to
purchase channel if either the client or server uses this new revision.

However, there will be some hassle for users but merging
this MR should not put any funds at risk.

* Added newline

Suggested-By: 2Fast2Bcn

* Update LSPS1/README.md

Co-authored-by: Elias Rohrer <dev@tnull.de>

* Update LSPS1/README.md

Co-authored-by: Elias Rohrer <dev@tnull.de>

* Fixes suggested by tnull

* LSPS1: JSON formatting

* LSPS1: Fix examples

* Update LSPS1/README.md

Co-authored-by: Elias Rohrer <dev@tnull.de>

* LSPS1: Clean up lsps1.get_info response

This commit changes `LSPS1.get_info` response.

# Don't wrap data in the options-field

All data was wrapped in the `options`-field. This field is useless since
[we removed the website from LSPS1](#96). @tnull suggested to not use the field anymore.

# Drop all payment related fields

I had included an `supports_onchain_payment`-field.
We don't include this data in `lsps1.get_info` anymore.
The client has to create an order and can see the payment options
subsequently.

Suggested-By: Elias Rohrer <dev@tnull.de>

* Fix typo

* LSPS1: Do not allow null-fields in `onchain`

An LSP should only include the `onchain` payment-option if it is willing
to accept `onchain` payments for that order.

Previously, we set the `onchain_address` to `null` to indicate that the
LSP did not accept `onchain` payments. This is no longer needed.

* LSPS1: Remove onchain payment tracking

The client should not rely on the LSP for transaction details of their
own payments.

Removing this fields simplifies the spec

* LSPS1: Rename `REFUNDED` to `CANCELLED`

For lightning invoice the `REFUNDED` state existed.
This name is not approriate cause in many scenario's the payment has
never happened in the first place.

* LSPS1: Use full lightning invoices

---------

Co-authored-by: Elias Rohrer <dev@tnull.de>