When a channel was force-closed, we previously stored partially created closing transactions for each output of the commitment transaction. In some cases those transactions didn't include any on-chain fee (HTLC txs
with 0-fee anchors) and weren't signed. The fee is set in the publisher actors which then sign those transactions.

This was an issue because we used those partial transactions as if they were the final transaction that would eventually confirm: this made it look like RBF wasn't an option to callers, and was thus easy to misuse.

We now change our data model to only store the outputs of the commit tx that we may spend, without any actual spending transaction. We only store spending transactions once they are confirmed, at which point they can safely be used as closing transactions by callers such as our balance checks.

This lets us get rid of some codec migration code related to closing transactions, and is more future-proof because we now don't need to encode closing transactions and can thus change their format easily. This also reduces the size of our channel state during force-close.

When we restart, we re-compute pending closing transactions, which means we potentially RBF transactions claiming our main output, which is a good thing. In the longer term, once we stop supporting non-anchor commitment formats, we should probably re-work the publisher actors to always automatically RBF those transactions.

⚠️ There is one unwanted noticeable change for recovery close: we never stored the remote per-commitment point, which means we aren't able to RBF our main transaction if necessary. Is this something we'd like to support?

❗ Reviewers should start reviewing the changes made to ChannelData.scala: that's the main change and goal of this PR. Then another important change is in Channel.scala when restoring a channel (reconnection) where we re-compute 2nd-stage and 3rd-stage transactions. The rest of the PR is just fixing existing code to work with the new format.