This was from the legacy onion, and is no longer present.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

There's currently a *description* of how to decrypt an onion, and some requirements
in forwarding.  But it also applies to onion messages, so:

1. Turn the description into actual enumerated requirements.
2. Ensure the description covers both payload and messaging onions.
3. Include both methods to apply the blinding tweak.
4. Leave the actual handling of the extracted payload (payment vs messaging onion) to those specific sections (e.g. reporting failure)

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…tlc/onion message requirements.

This ties it together, saying what to use as associated data, blinding, and what to do on failure.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Sure, it's used to derive a secret for blinding, but it's also used to derive the key
for encrypted_recipient_data.  It's not used as a blinding factor *directly*.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This commit doesn't change the logic at all, it simply:

- removes `realm` from onion test vector
- cleans-up markdown formatting and indents
- fixes typos and missing parenthesis
- consistently uses `_` instead of `-` for field names
- fixes math formatting (including changes from lightning#1169 and lightning#1158)