This commit extends the specification with a new commitment format that
adds two anchor outputs to the commitment transaction. Anchor outputs
are a safety feature that allows a channel party to unilaterally increase
the fee of the commitment transaction using CPFP and ensure timely
confirmation on the chain. There is no cooperation required from the
remote party.

Anchor outputs

Many channels use a value below 6, which is really insecure (there are
more than 2k such channels on mainnet).

While less risky, there are more than 7k channels with a value below 12.

This indicates that the spec should probably make the risks a bit more
clear to help guide node operators.

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

We use a modified version of the PoDLE implemented and used by
JoinMarket for lightning opens (and optionally any other collaborative
transaction construction protocol).

The original PoDLE implementation and implementation notes are available
at https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/4bf1f50d4e4226b00fd5a8bd39673faceac9da51/jmclient/jmclient/podle.py#L92-L118

The NUMS J point original implementation can be found at https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/4bf1f50d4e4226b00fd5a8bd39673faceac9da51/jmclient/jmclient/podle.py#L203-L235

In order to effectively deter bad behavior, we gossip bad behavior
P2 commitments via a blacklist_podle message

Suggested-By: Nadav Kohen @nkohen

To prevent infinite loops, we set the max additions/subtractions to
2^12 (4,096).

If each side sends the maximum allowed messages, this is a total of
32,768 messages (2^12 * 4 * 2). (The end result of this exchange would
necessarily be an empty tx, as the number of adds would equal the number
of removals).

In practice, this bounds the total inputs/outputs to 2*13 (8,192) each.