Allow configurable per-payment min_final_cltv_expiry

[TheBlueMatt]

This is actually really important for some users (ie those doing swaps). We currently require users just use the hard-coded LDK final_cltv_expiry values. To change this, we'll need to encode the min_final_cltv_expiry value in the payment secret in ( in the inbound_payment.rs form), which will get pretty packed.

I think we can do it, though - we only really need to store a min_final_cltv_expiry up to a few days, maybe a week. If we use 12 bits for the expiry, that gives us up to ~28.5 days worth of expiry, and no one should really be creating HTLCs that last longer than that anyway. We can pretty easily take 8 or 9 bits from the expiry time we store in the payment_secret - we only compare it to the block height, which is basically +/- 600 sec anyway, so let's say we take 8 bits and round down to the nearest 256. Now we have to shave 4 bits off the amount, which already lost 3 bits on the payment type (we'll have to add two new payment types, but that still leaves 4). This leaves 57 bits for amount, or 1.44 million BTC, which I this is more than enough for any single payment.

[TheBlueMatt]

Tagging 114 since users want this.

[TheBlueMatt]

Also we need lightning-invoice utils to construct invoices with different expiries.

[dunxen]

Ok, I can work on this one when I need dual-funding breaks :)