Improved channel_state_changed notifications

[cdecker]

We currently have the channel_state_changed notifications
(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.