Add helpers to create `LocalCommitmentKeys` and `RemoteCommitmentKeys`
from commitment parameters.

Add helpers to create `LocalCommitmentKeys` and `RemoteCommitmentKeys`
from a `Commitment` instance and start relying on this constructor.

We now create all commitment-related transactions using commitment keys
instead of explicitly using a subset of the public keys used.

Note how this highlights that many tests in `TransactionsSpec.scala`
were actually using incorrect keys, and thus not really testing the
correct behavior. This is a very good proof that making this simpler
is a good choice, because that kind of issues can also happen in non
test code (and has happened in the past already).

Instead of taking as argument individual keys (that can be incorrectly
provided), our functions to create witnesses and scripts now use the
commitment keys classes.

We were previously going through the `ChannelKeyManager` to sign txs
just to end up calling `TransactionWithInputInfo.sign` after applying
some key derivation. This was confusing and is now unnecessary: we can
directly call `TransactionWithInputInfo.sign` since the new commitment
keys directly contain the correctly tweaked keys.

The `ChannelKeyManager`'s responsibility is now simply to derive the
keys and ensure that different channels use different derivation paths.
Unfortunately, we still need to call it in a few different places to
obtain the channel key path and then derive some of our keys. This can
be improvied: we will go further in the following commits to simplify
this.

The `ChannelKeyManager` previously had two distinct roles:

- generating random funding key paths for new channels
- generating channel keys from a funding key path

This was confusing and forced all the code that wanted to derive channel
keys to always first get the channel key path from the key manager and
then call the function it was interested in with this channel key path
as argument.

We remove this confusion by having the `ChannelKeyManager` only generate
funding key paths for new channels and initialize `ChannelKeys` based on
a given funding key path. The new `ChannelKeys` object provides direct
access to derivation functions for all the keys necessary. Each channel
has its own `ChannelKeys` object that only lets it derive keys for its
own usage.

Reviewers should start by reviewing the changes to `ChannelKeyManager`
and `LocalChannelKeyManager`: the rest is mostly mechanical changes to
use this new architecture.

We also refactor a bit the functions in `Commitments.scala` to derive
commitment keys as early as possible and then provide them as arguments
to the child functions.

This commit trivially:

- moves `ChannelKeys` to its own file
- moves `CommitmentKeys` in the `keymanager` package

It doesn't contain any business logic.

We move the commitment key derivation logic inside `ChannelKeys`, which
makes it easier to understand the various types of derivation involved
in channel keys.

We also explicitly pattern match on `commitmentFormat` when deciding
whether the payment key needs to be tweaked for each commitment or not,
which makes it more future-proof. It is a bit confusing because we did
not introduce a `commitmentFormat` for `option_static_remotekey`, which
applies either to anchor outputs or the default commitment format when
the corresponding channel feature is turned on.

We rename `xxxSecret -> xxxPoint` curve points that are only used when
tweaked and never appear directly as public keys inside scripts. This
better matches the BOLTs and helps distinguish keys used for signing.