We don't need this helper for other transactions: it is only used to
verify the remote signatures received in `commit_sig`.

In this commit, we somewhat heavily re-design `Transactions.scala`. The
main change is that we stop exposing the default `sign` function that
was too abstract for callers, and have each `TransactionWithInputInfo`
expose its dedicated `sign` function, with simpler arguments depending
on each transaction type.

One very important thing to note is that there is a heavy distinction
between transactions that require both a local and a remote signature
(commit-tx, splice-tx, closing-tx and htlc-tx) and transactions that
only need a local signature. This means we can completely remove the
`addSigs` step for transactions that only need a local signature, and
directly create signed signatures, which simplifies the calling code.

This also lets us better encapsulate the `extraUtxos` parameter, which
only makes sense for txs for which we add wallet inputs, which is only
a small subset of our transactions.

The previous commits ensured that we store the data we need for each
transaction type to allow re-deriving and signing everything based
only on the following runtime data:

- the commitment format
- the commitment funding keys
- the commitment keys

This makes the calling code much less error-prone and removes the need
to store the redeem script in the `InputInfo` class, which wouldn't
have worked for taproot transactions. Note that for simplicity's sake,
we currently keep the field (to avoid a painful codecs migration) since
we will introduce v5 codecs when implementing taproot channels, which
will let us clean up this inconsistency.

We also move each transaction's creation function in its companion
object: this makes the diff a bit harder to review, but ensures that
each transaction's implementation is well encapsulated, which makes
it easy to review that each transaction type is correctly implemented.

Instead of using placeholder signatures when evaluating the weight of
transactions, we actually sign them. This means we sign twice, but is
not a performance issue in this case because it only happens once when
we initiate a force-close, and simplifies the code.

We also introduce a `RedeemInfo` trait which makes the code forward
compatible with taproot channels. The changes to `Transactions.scala`
are a lot to review, but unfortunately I didn't find a good way to
split them while having something consistent and all the unit tests
passing...

We also rename this function, which didn't make any sense: we are not
checking that this transaction is spendable (which means that we could
spend its *outputs*), but rather that the transaction is fully signed
and valid.

Transactions that spend the channel funding output don't behave the
same way as transactions that can be unilaterally signed, so it makes
sense to use different traits. This lets us better scope our shared
code and remove unused parameters (e.g. sighash is much simpler for
transactions spending the channel funding output and the concept of
`TxOwner` is unnecessary).

We also take this opportunity to explicitly separate the two distinct
signing cases for `ChannelSpendTransaction`: 2-of-2 multisig and musig2,
which create different signature types. By pattern matching on the
commitment format, callers should decide whether they want to produce
an individual signature or a partial signatures. This may need some
rework to fully adapt to taproot, but it has the benefit of exposing
which part of the code should be concerned about the type of sigs it
creates.

Anchor signing functions will either use the local or remote commitment
keys for taproot commitments, depending on whether the local or remote
commitment has been broadcast.

Add the actual commit tx output to CommitmentOutput.
Add the 2nd-level HTLC output to InHtlc/OutHtlc.

We remove the re-creation of closing transactions on restart in favor
of a cleaner codec migration. We add test vectors generated from the
`master` branch.