Simplify outgoing payment state machine

[t-bast]

We previously supported having multiple channels with our peer, because we didn't yet support splicing. Now that we support splicing, we always have at most one active channel with our peer. This lets us simplify greatly the outgoing payment state machine: payments are always made with a single outgoing HTLC instead of potentially multiple HTLCs (MPP).

We don't need any kind of path-finding: we simply need to check the balance of our active channel, if any.

We may introduce support for connecting to multiple peers in the future. When that happens, we will still have a single active channel per peer, but we may allow splitting outgoing payments across our peers. We will need to re-work the outgoing payment state machine when this happens, but it is too early to support this now anyway.

This refactoring makes it easier to create payment onion, by creating the trampoline onion and the outer onion in the same function call. This will make it simpler to migrate to the version of trampoline that is currently specified in https://github.com/lightning/bolts/pull/836 where some fields will be included in the payment onion instead of the trampoline onion.

Builds on top of #660.