Expose pending HTLCs and dust exposure in ChannelDetails

[f3r10]

While working on ldk-server I ran into ldk-server#251, which tried to expose more channel data over its API but had to leave out pending HTLCs and dust exposure, because ldk-node's ChannelDetails doesn't include them.

Looking at ChannelDetails::from_ldk in src/types.rs, LDK's ChannelDetails already has these fields, but we don't copy them over:

• pending_inbound_htlcs: Vec<InboundHTLCDetails>
• pending_outbound_htlcs: Vec<OutboundHTLCDetails>
• current_dust_exposure_msat: Option<u64>
• next_splice_out_maximum_sat: u64

The HTLC details include the amount, CLTV expiry, payment hash, state and whether the HTLC is dust (plus skimmed_fee_msat for outbound ones).

I think these would be useful for:

• debugging stuck payments, e.g. seeing which HTLCs are still pending on a channel and when
  they expire
• checking how close a channel is to its force-close deadline
• comparing current_dust_exposure_msat against the channel's max_dust_htlc_exposure config
• showing how much can be spliced out before calling splice_out

LND and CLN both show pending HTLCs when listing channels, so node operators are probably used to having this. tnull also mentioned in #163 that most ChannelDetails fields would make sense to expose, and #993 already reads pending_outbound_htlcs internally for LSPS5 notifications, so this data seems useful outside LDK too.

For the bindings, I guess the HTLC detail structs and the InboundHTLCStateDetails / OutboundHTLCStateDetails enums would need uniffi wrappers, similar to what we do for ChannelShutdownState in src/ffi/types.rs.

I left splice_details out on purpose since there's ongoing work on splice tracking (#1080, #1079, #1057) that already uses it internally, but it could be added later if that makes sense.

Does this sound reasonable? I'd be happy to work on it. @tnull @TheBlueMatt

[tnull]

Yeah, makes sense, now done in #1103.