When a channel is closed we want to remove its HTLCs from our
list of pending broken HTLCs (they are being resolved on-chain).

We should also ignore outgoing HTLCs that have already been
settled upstream (which can happen when downstream is closing).

When a downstream channel is closing, we can safely fail upstream the
HTLCs that were either timed out on-chain or not included in the
broadcast commit transaction.

Channels will not always raise events about those after a reboot, so we
need to inspect the channel state and detect such HTLCs.

To extract the payment_hash or preimage from an HTLC script seen on-chain.

With MPP, it's possible that a channel contains multiple HTLCs for the
same payment hash, and potentially even for the same expiry and amount.

We add more fine-grained handling of HTLC timeouts that share the same
payment hash. This allows a cleaner handling after a restart, and makes
sure we correctly detect failure that should be propagated upstream.
Otherwise we wouldn't be losing any money, but some channels may be closed
that we can avoid.

A couple refactorings to avoid duplication and some clean-up.

It may happen that a commit tx and some htlc-timeout txs end up in the
same block. In that case, there is no guarantee on the order we'll receive
the confirmation events.

If any tx in a local/remoteCommitPublished is confirmed, that implicitly
means that the commit tx is confirmed (because it spends from it).
So we can consider the closing type known and forward the failure upstream.