…useful"

This reverts commit eb882a6.

The reverted commit introduced a regression causing the subchannel
open protocol to hang because a particularly large message was not
being sent over in full (one of the chunks was seemingly stuck).

I've backported from the 0.0.118 release since it seems like we could
easily run into this by attempting to close a channel that is already
closed or that never existed in the first place.

`Channel` is only a thing for funded channels. Thus, checking if a
channel has not yet been funded is dead code and can simply be
elided.

…ht place

Because a `Funded` `Channel` cannot possibly be pre-funding, the
logic in `ChannelManager::close_channel_internal` to handle
pre-funding channels is in the wrong place.

Rather than being handled inside the `Funded` branch, it should be
in an `else` following it, handling either of the two
`ChannelPhases` outside of `Funded`.

Sadly, because of a previous control flow management `loop {}`, the
existing code will infinite loop, which is fixed here.

…o chan

Previously, unfunded channels would be stored outside of
`PeerState::channel_by_id`, and thus if there is no channel when
we look in `PeerState::channel_by_id`, `close_channel_internal`
called `force_close_channel_with_peer` to hunt for unfunded
channels.

However, that is no longer the case, so the call is redundant, and
we can simply return an error instead.

If you want to check what CI says you can always just open a (draft)
PR.

Most PRs target `main`, but for those PRs that target a different
branch it is more efficient to target the PR base branch.

Otherwise we can end up running the script for too many commits and
run into a timeout on CI.

The (de)serialisation for `ChannelTransactionParameters` changed
between 0.0.114 and 0.0.116. This type had already been modified by us
when adding the `original_funding_outpoint` field. When first
introduced, we chose a type value of 14.

After the update, we chose to reduce it down to 12 since the type 12
was no longer being used after changes between 0.0.114 and 0.0.116.
Unfortunately, this unnecessarily broke channels created before the
update.

Eventually we will need to settle on a way to handle these possible
conflicts with upstream. Tibo already suggested a few options:

- Use much larger numbers for `rust-dlc` custom fields.
- Move LDK values around as we rebase on top of new changes.
- Add a subdomain for `rust-dlc` custom fields.

It would be even nicer to log the `ChannelDetails`, but then we would
have to modify the macro and that is too painful.