Add `min_final_cltv_expiry` and `first_csv_expiry` to `swap_in_request`

As discussed in detail about forwardable peerswaps, these need to be added to the protocol so that forwarders can decide whether it is safe to further forward the peerswap, or if it has to be handled here.

`first_csv_expiry` is the `R` parameter currently hardcoded to 1008 for Bitcoin and 60 for Liquid.

`min_final_cltv_expiry` promises to issue the invoice with the `c` field set to that value.

In the forwarding case, a potential forwarder MUST:

* Check `first_csv_expiry > min_final_cltv_expiry`.
* Check that `first_csv_expiry - min_final_cltv_expiry > 504`.
* If it decides to forward, check `first_csv_expiry - min_final_cltv_expiry > 504 + cltv_delta`, where `cltv_delta` is the parameter it uses for channels.
* If it decides to forward, it should forward the next hop `min_final_cltv_expiry` to the received `min_final_cltv_expiry + cltv_delta`,