Clean up handling of HTLC failures

[TheBlueMatt]

A bunch of ideas came up in review of #1077 showing our current onion failure processing isn't really expressive enough. Post-1077 we should really do some cleanup.

• We should inform the user when their immediate channel partners are failing HTLCs for reasons we don't think are legitimate - this probably means we need to close the channel, but I feel a bit uncomfortable doing so ourselves.
• We have historically synthesized NetworkUpdates when we think the sender of an HTLC failure gave us a bogus reason, telling our network graph to just remove the channel. Now that we have the ability to de-prioritize a channel, we should maybe just 10x-deprioritize a channel instead of removing it for a "bogus" failure,
• We ended up with somewhat overlapping NetworkUpdate and short_channel_id fields in PaymentPathFailed, as they're used for two separate things ("punishing" a channel in our router, and providing an update that a peer provided us). This is fine for now, but especially if we move forward with the above, we'll want to just have one FailureReason or something like that that has different states and contains the SCID and any network updates.

[valentinewallace]

Per this convo, NetworkUpdate::ChannelClosed also needs a rename https://github.com/rust-bitcoin/rust-lightning/pull/1077#discussion_r727443473