This commit adds the interactive transaction construction protcol, as
well as the first practical example of using it, v2 of channel
establishment.

Note that for v2 we also update the channel_id, which now uses the hash
of the revocation_basepoints. We move away from using the funding
transaction id, as the introduction of RBF* makes it such that a single
channel may have many funding transaction id's over the course of
its lifetime.

*Later, also splicing

Requested-by: @t-bast

While dual funding only needs unsigned funding amounts, other protocols
that leverage interactive-tx may use signed funding amounts, for example
to take funds out of an existing channel (splice-out).

It is thus more future-proof to use signed amounts in `tx_init_rbf` and
`tx_ack_rbf`.

Repeat the second commit point in the initial openchannel2 +
acceptchannel2 messages.

Suggested-By: @pm47

Prior versions of the v2 dual-funding protocol assumed a 'minimum fee'
payment for any witness stack of any input, as a way to simplify fee
checks.

The suggested min feerate didn't make sense for taproot spend paths etc;
instead we remove this check entirely.

This lets any side of the protocol require the other side to use confirmed
inputs, to avoid paying the fees of a low feerate unconfirmed ancestor.

This issue is non-trivial and worth mentioning, otherwise implementations
may forget to handle this which would result in an easy way of attacking
node's on-chain liquidity, creating a large opportunity cost.

If we only store state when sending `tx_signatures`, there are cases where
we cannot reconcile states if a disconnection occurs during the signing
steps: one side will have sent `tx_signatures` and thus must wait for the
transaction to be spent or double-spent, while the other side has already
forgotten that channel because they haven't sent `tx_signatures`.

This is fixed by storing state when sending `commitment_signed`, and
adding a `next_funding_txid` field to `channel_reestablish` to ask our
peer to retransmit signatures that we haven't received.

Suggested-By: @dunxen

This was previously assumed but adding it to the spec makes it explicit, should we ever want to change it in the future.

Suggested-By: @morehouse

`tx_abort`'s structure comes from the `warning`/`error` messages,
but we failed to port over the rationale/rules for the `data` field.

Suggested-By: @morehouse

Found-by: @morehouse

Suggested-By: @morehouse

Reported-By: @morehouse

Suggested-By: @devrandom

Suggested-By: @morehouse

Moved up some rationale from the Rationale section and added a
bit of clarification to when you'd want to close/cancel an open.

Reported-By: @morehouse

Make `require_confirmed_inputs` explicit for RBF regnegotiation.

Requested-By: @t-bast