Upgrade channel type when splicing

[t-bast]

We add a basic mechanism to opportunistically update the channel_type when splicing. This uses the same TLV field as open/accept channel and a similar mechanism. We don't explicitly detail every channel type that is allowed, and this will evolve depending on which channel types are supported by multiple implementations.

Each implementation should decide on its own policy for which upgraded channel types are available. The frequency at which we ship new channel types to the network is slow enough that we don't need a more complex protocol to thoroughly handle mismatches. The most likely outcome is that implementations will only allow the following transitions:

• upgrading to anchor_outputs from a pre-anchor channel
• upgrading to simple_taproot from an anchor or pre-anchor channel
• upgrading to taproot_zero_fee_commitments from any other channel type

This becomes more interesting once we've also integrated #1324, which adds the nonce fields to interactive-tx that are necessary for musig2.

Note that I opted for an odd TLV without a feature bit. It seems simpler to me to always opportunistically provide a channel_type in splice_init to try upgrading: nodes that don't support it will not send back a channel_type in splice_ack, and at that point the initiator can decide to either abort or move forward with the splice anyway without the channel_type upgrade (if it was splicing-in or out anyway, which is valuable regardless of the channel_type change).

One open question that I didn't address is that v3 transactions have stricter limits than v2 transaction: max_accepted_htlcs cannot exceed 114 for example. Do we want to simply implicitly trim those channel parameters on upgrade?