zero-conf: cleanup channeldb scid representation

[Crypt-iQ]

From: #8963 (comment)

This has caused lots of confusion about when to use OpenChannel.ShortChannelID() vs OpenChannel.ZeroConfRealScid. The ShortChannelID is the first alias that we send to the peer and the graph stores info under this scid. When the channel reaches six confirmations, the ZeroConfRealScid() function returns the on-chain scid and the graph info is then moved to be stored under this scid. We should have some function to determine which SCID to use or perhaps replace the OpenChannel.ShortChannelID member when the channel confirms.

[ProofOfKeags]

I think we actually need to unify all the methods of identifying a channel:

1. ChannelID
2. SCID
3. Alias
4. Outpoint

There should be an easy mechanism for converting between all of the actual representations and functions can then take the union of them and should they need to encode it they can easily convert it to the representation they need for wire or disk encodings.

The primary issue is that I believe we chose, in the interest of expediency, to abuse the data field we had for the SCID to store the ZeroConf alias because a real SCID was not available by the time the field needed to be populated. We can probably make the terms consistent by giving the channel a "primary identifier" value and some sort of type identifier declaring what the primary identifier actually is. Then we can make SCID, and Alias both return Option values depending on the situation, knowing that there is always one short primary identifier.

[guggero]

We should also make sure the link doesn't need to have its own maps between base SCID and alias but can instead fully rely on the alias manager to have the most up-to-date view.

That would allow us to remove the UpdateLinkAliases callback introduced in #9049 again.