[kwsantiago]

After a reconnect, a peer's tx_abort for a splice we initiated but never sent tx_signatures for failed the channel: our signature on the shared input, made when the inflight is created, counted as sent. These changes decide that from what was actually sent and received, and make sure what is stored matches what the peer has.

• channeld sends splice tx_signatures only after lightningd answers a new channeld_splice_sending_sigs_reply, so i_sent_sigs is committed before the peer can hold our signatures.
• check_tx_abort refuses a peer tx_abort once we have sent tx_signatures, once we hold the peer's signatures (remote_tx_sigs, its signature on the shared input, or a finalized shared input), or, as accepter, once we have signed. Our early signature as initiator no longer counts on its own.
• A migration marks initiator splice inflights stored by releases that did not update i_sent_sigs as having sent signatures, keeping the behavior those releases had.
• New inflights start with remote_tx_sigs false.
• lightningd stops handling a splice abort when it has no inflight or the outpoint does not match its last one, failing any pending splice command.

Tests in tests/test_splicing.py, each failing without its change:

• test_splice_peer_aborts_unsigned_after_reconnect: the peer's tx_abort after a reconnect drops the unsigned splice and the channel stays usable.
• test_splice_sigs_sent_after_commit: with lightningd exiting before it replies (--dev-splice-exit-before-sending-sigs), the peer never receives our tx_signatures, as initiator or accepter, and the splice completes after restart.
• test_splice_tx_abort_refused_with_their_sigs: a tx_abort is refused for a splice whose peer signatures we hold, and the splice is recognized when it confirms.
• test_splice_sent_sigs_marked_on_upgrade: an initiator inflight as older releases stored it is refused after the upgrade.

Changelog-None