Trampoline routing uses layered onions to trustlessly and privately offload
the calculation of parts of a payment route to remote trampoline nodes.

A normal onion contains a smaller onion for the last hop of the route, and
that smaller onion contains routing information about the next trampoline hop.

Intermediate trampoline nodes "fill the gap" by finding a route to the next
trampoline node, and sending it the peeled trampoline onion, until that
reaches the final destination.

When paying a Bolt 12 invoice, the payer may use a trampoline node to
relay that payment. The payer simply includes some of the blinded paths
in the onion payload for the trampoline node, who will relay to those
blinded paths. The trampoline node doesn't learn anything about the
final recipient.

We only support using a single trampoline node, because we must provide
the blinded paths in the outer onion, instead of the trampoline onion.
If we included them in the trampoline onion, the trampoline node would
not have enough space in the outer onion to correctly relay the payment.

If the recipient supports trampoline and the `invoice_request` contains
the trampoline feature bit, the recipient may set it in its invoice. In
that case, the sender can include a trampoline onion to provide custom
TLVs to the recipient. We prevent the trampoline node from replacing
that onion with one that it created by using a shared secret created
from the `invoice_request` to authenticate that onion.

Note that this commit depends on Bolt 12: it references a few types that
are introduced in various commits related to Bolt 12 (e.g. `blinded_path`
and `blinded_payinfo`), which can be confusing since Bolt 12 spec is
still in progress. I will clean this up once Bolt 12 is finalized.