Clarify nonce size for onion cipher

Some ChaCha20 implementations API's support both 64- and 96-bit nonces, while
others only support a single one.

Functionally, both nonce sizes are equivalent for LN usage, since the
nonce is always zeroed. However, while evaluating spec compliance of
ChaCha20 libraries, the fact that some do not support the 8 byte nonce
variant prompted a closer investigation about the nonce requirement.

Since RFC8439 is the one linked to in the current BOLT0004 spec and that
RFC only specifies the 96-bit nonce variant, that requirement is made
more explicit by this commit.

04-onion-routing.md

@@ -78,8 +78,8 @@ There are a number of conventions adhered to throughout this document:
  - Elliptic curve: for all computations involving elliptic curves, the Bitcoin
    curve is used, as specified in [`secp256k1`][sec2]
  - Pseudo-random stream: [`ChaCha20`][rfc8439] is used to generate a
-   pseudo-random byte stream. For its generation, a fixed null-nonce
-   (`0x0000000000000000`) is used, along with a key derived from a shared
+   pseudo-random byte stream. For its generation, a fixed 96-bit null-nonce
+   (`0x000000000000000000000000`) is used, along with a key derived from a shared
    secret and with a `0x00`-byte stream of the desired output size as the
    message.
  - The terms _origin node_ and _final node_ refer to the initial packet sender
@@ -127,7 +127,7 @@ The pseudo-random byte stream is used to obfuscate the packet at each hop of the
 path, so that each hop may only recover the address and HMAC of the next hop.
 The pseudo-random byte stream is generated by encrypting (using `ChaCha20`) a
 `0x00`-byte stream, of the required length, which is initialized with a key
-derived from the shared secret and a zero-nonce (`0x00000000000000`).
+derived from the shared secret and a 96-bit zero-nonce (`0x000000000000000000000000`).
 
 The use of a fixed nonce is safe, since the keys are never reused.