Improved `channel_state_changed` notifications

We currently have the `channel_state_changed` notifications
([docs][channel_state-docs]) that is emitted whenever the state of the
channel state machine changes. This is rather coarse-grained, and is
missing an orthogonal state: the connection status of the peer
connection this channel is managed over.

So we end up tracking two separate state machines:

- Channel state machine: the long-lived channel, independent from its
current connection status
- Connection state machine: the short-lived status telling us whether
the channel is actually usable or it would just be if the peer were
connected.

We found that the coarse grained notifications are not detailed enough
to make informed decisions. In the case of an always-on node it may be
ok to assume that any channel that is connected and `CHANNELD_NORMAL`
can also be used, however that leaves the window open for the
`connection_state=connected` + `channel_state=CHANNELD_NORMAL` state,
because the peer may have just reconnected, and we might still be
exchanging `WIRE_REESTABLISH` messages. If we try to use the channel
in this state we'll get an error for the first peer not being
ready. This can be hit by any node, but Greenlight nodes regularly
have this situation, and we partially addressed it by tailing the logs
and tracking the state ourselves. However we believe this could be
useful for any node operator and a good basis for more advanced
plugins.

## Possible Solutions

This issue can be solved in two ways:

1. Amending the existing `channel_state_changed` notification to also
include the connection state. This means we are now emitting the
notification more often, i.e., the same `new` state will be
signaled multiple times, when we have a connection state machine
change we'd end up with a notification with `old_state` and
`new_state` are the same, but a new `connection_state` would tell
us what changed in the connection.
2. Create a new `channel_state` notification, whose semantics are
defined as returning the vector of states, and being emitted
whenever _any_ of the states changes. This has the advantage of
not breaking existing listeners of `channel_state_changed`, but
comes with a whole new notification, and we'd likely want to
deprecate `channel_state_changed` to minimize redundancy.

[channel_state-docs]: https://docs.corelightning.org/docs/event-notifications#channel_state_changed