We now support splicing on public channels: once the splice transaction
is confirmed and locked on both sides, nodes will exchange announcement
signatures that allows them to create a `channel_announcement` that they
then broadcast to the network.

This requires reworking the data model to include the announcement and
the real `short_channel_id` in each commitment, which lets us cleanly
distinguish real `short_channel_id`s from aliases (which are set at the
channel level regardless of the current commitments).

The flow now becomes:

- when the funding transaction of a commitment confirms, we set the
  corresponding real `short_channel_id` in that commitment
- if the channel is public and we've received `channel_ready` or
  `splice_locked`, we send our `announcement_signatures`
- if we receive `announcement_signatures` for a commitment for which
  the funding transaction is unconfirmed, we stash it and replay it
  when the transaction confirms
- if we receive `announcement_signatures` for a confirmed commitment,
  and we don't have a more recently announced commitment, we generate
  a `channel_announcement`, store it with the commitment and update
  our router data

When creating a `channel_update` for a public channel, we always use
the `short_channel_id` that matches the latest announcement we created.
This is very important to guarantee that nodes receiving our updates
will not discard them because they cannot match it to a channel.

For private channels, we stop allowing usage of the `short_channel_id`
for routing: `scid_alias` MUST be used, which ensures that the channel
utxo isn't revealed.

Note that when migrating to taproot channels, `splice_locked` will be
used to transmit nonces for the announcement signatures, which will be
compatible with the existing flow (and similarly, `channel_ready` will
be used for the initial funding transaction). They are retransmitted
on reconnection to ensure that the announcements can be generated.