Consider setting RBF flag for Lightning funding transactions

Read the RBF and fee-bumping logic in electrum/lnpeer.py and electrum/wallet.py, including the linked lines. Compare the funding-transaction, bump_fee, and dscancel behavior with the multi-device and channel-recovery concerns described here. Done requires a decided, safe policy for RBF and fee actions, but this issue does not specify an implementation or tests.

Currently we intentionally don't set the RBF flag for LN funding transactions (channel opening txs).
https://github.com/spesmilo/electrum/blob/84326cf1f78f60201e5bac44ff306c240147adde/electrum/lnpeer.py#L686

This means that if the user lowballs the fee, the funding tx can get stuck in the mempool in limbo for a very long time, and the user has essentially no recourse: all they can do is wait.

To be clear, with current the Lightning/BOLT v1 spec, it is not possible to non-destructively bump the fee of a funding transaction. That is, if we bump the fee and keep the funding output, the txid changes which invalidates the channel id, and the remote peer will not find the funding outpoint -- the funds then can only be recovered manually through with the help of the channel counterparty.
Bumping the fee should be possible in the future with the channel v2 spec (https://github.com/lightningnetwork/lightning-rfc/pull/524), but naturally only in a collaborative way (the peers need to exchange messages).

Code in wallet.py only allows bumping the fee of a tx that both (1) opted in to RBF, and (2) is not a LN funding tx for one of our channels:
https://github.com/spesmilo/electrum/blob/84326cf1f78f60201e5bac44ff306c240147adde/electrum/wallet.py#L618
https://github.com/spesmilo/electrum/blob/84326cf1f78f60201e5bac44ff306c240147adde/electrum/wallet.py#L647-L648

As said at the beginning, we don't set RBF for our funding txs, so check (2) is actually not relied on right now.

The issue is that not opting in to RBF not only disables bump_fee but also e.g. double-spend cancelling the tx:
https://github.com/spesmilo/electrum/blob/84326cf1f78f60201e5bac44ff306c240147adde/electrum/wallet.py#L619
(and not just in the code but on a bitcoin p2p relay level as well).

So, we could opt-in to RBF, detect the tx is a funding tx, and not allow bump_fee but still allow dscancel.
Further, advanced users can always manually craft conflicting txs that spend the coins in a custom manner, but relaying the tx on bitcoin peer-to-peer is kind of hopeless without opt-in RBF.

However, what if the user uses the same wallet (seed) on multiple devices?! Check (2) only works on the device that has the Lightning state for said channel. If we opt-in to RBF, the user might shoot themselves in the foot and run bump_fee on the funding tx on another device.

Note that even with channel v2, this core problem remains: and it actually becomes more likely I expect! LN peers likely will want to opt-in to RBF, and users with multiple devices might run bump_fee on the funding tx - and the second device does not know to notify the channel counterparty about the replacement.

Note that we have been thinking about putting an OP_RETURN output on funding txs, with some encrypted data, for channel-recovery purposes. That would also mitigate this, if the second device is able to decrypt the data and identify the tx as a funding tx (and disable bump_fee in that case in the UI).