Support multiple funding transaction (candidates) per channel (Splicing, Dual Funding)

[optout21]

Currently one channel has one funding transaction, this is expected to change with Dual funding and Splicing use cases. This issue is created to collect some of the concerns.

Current setup

A channel has one funding transaction, initially unset. During the channel opening process it gets set, then confirmed. Afterwards it does not change during the lifetime of the channel.

New use cases

V2 channel opening with RBF. It is possible to RBF a pending funding transaction, so it is possible to have two -- or more -- funding candidates. It is not known which will confirm first.

Spicing. In the transitional period before the new spliced funding transaction is confirmed, both old and new funding has to be kept. Only the new one can confirm, but at close both have to be attempted to closed (it is not known if old has been already spend by the new or not yet).

Splicing plus RBF. A combination of the above.

Some concerns

• Currently channel has several fields keeping info about the funding transaction, these should be grouped for convenience. See Group channel funding transaction fields (small refactor) [splicing] #2736.
• An additional structure for holding multiple funding TX candidates should be introduced. Probably a map where ID is TXID. It should be persisted.
• When transactions get confirmed, we need to check against all candidates (not just against the single funding TX)
• The existing field(s) should be kept and used for already locked funding TX, and for pending in the case of V1 opening. For V2 opening and Splicing, funding candidates should be kept in the new map.
• Serialization b/w compatibility: the serialization of existing funding TX fields should not change. The new map should be serialized separately.
• Support reorg. With a chain reorg it is possible that a confirmed transaction becomes unconfirmed. This is handled, and it should be handled similarly for multiple candidates.
• Exclusivity, what happens with other candidates if one gets locked? In case of RBF only one of the candidates can confirm, but the others still need to be kept around for the case of an eventual reorg. It's also more robust not to assume that only one can get locked.
• Channel closing: In case of Splicing, the pending candidate(s) needs to be considered, but the old funding tx as well (e.g. if the new funding was broadcast but rejected and will never lock).

[optout21]

Note: related: #3281

[optout21]

A current proposal for channel states/phases is described here: https://gist.github.com/optout21/2ead7a0f4e2c3d34aed1c9703c8cfb39