Explicit channel type negotiation

[t-bast]

This PR implements lightning/bolts#880

Now that we have multiple types of channels ("standard" channels, static remote key, anchor outputs and anchor outputs with 0-fee htlc txs), we need a mechanism to choose which one we want to use when a new channel is opened. Up until now, this choice was made based only on feature bits (from the init message) and considering that the newest channel type was always better.

That deterministic behavior is quite limiting: what if we want to experiment with anchor outputs (or another commitment type) by opening a few channels that we carefully control and monitor, while keeping a reduced exposure to it? You must activate the feature, which means that any node that also has the feature and sends you an open_channel message will be able to create an anchor outputs channel - and you can say goodbye to your limited exposure.

In order to fix this, we introduce an explicit negotiation of what channel type to use.
In open_channel, the funder sends the list of channel types it supports, ordered by preference.
The fundee chooses one that he likes and sends its response in accept_channel.
If the fundee doesn't want any of these channel types, it can reject the channel open.

That unblocks the scenario described above. A node that wants to experiment with anchor outputs can activate the feature without putting it into its list of supported channel types. It will safely reject all open_channel that use anchor outputs, and can manually open some anchor output channels by overriding the default list of channel types through the open API.

While it sounds simple, it raises a few issues. First of all, I don't like our current ChannelVersion. This is not a channel "version" and it contains two very different things: a set of channel features (standard vs static_remotekey vs anchor_outputs) and a set of internal configurations (a key derivation scheme). I'd like to rename it to a ChannelInternalConfig that currently only contains USE_PUBKEY_KEYPATH (and maybe later contains others choices of key derivation based on user preference). And we should store separately the channel_type (which is in fact the set of Bolt 9 features that govern the channel's behavior). This will become even more true as we add more channel features to the spec that are orthogonal to the commitment format (such as option_simplified_commitment, which would change the rules of who can send what messages when). The issue is that this requires a migration on the channels codec, which is a bit overkill for just this small change. But since #1846 requires a channel codec change, we could bundle these two changes together.

Second, what do we do with peers that don't support explicit channel type negotiation (which isn't advertised via a feature bit)? When we're fundee, it's simple: when we receive open_channel we can decide whether we want to accept the channel or not. But when we're funder it's more tricky: we will discover if they support it only when we receive accept_channel, and then it's too late, if they didn't support channel type negotiation we have to configure the channel based on feature bits only. It means that if we have activated anchor outputs, but send a channel_open without anchor outputs in it (because we're still experimenting with it only on a limited set of channels) and the fundee doesn't support negotiation, we should open an anchor outputs channel. Currently that's the behavior I've kept, but we could change it to fail the channel when we receive accept_channel. I think it would be the right thing to do, otherwise node operators may be surprised by the resulting channel.

Thoughts?