[noise] Noise "conventions" vs the Noise core

[Trevor Perrin]

There's a tension between making Noise a flexible and reusable core,
versus providing defaults for length fields, version fields, and
padding.

On the one hand we want people to be able to adapt Noise into their
own protocols.  One the other hand, we'd like users to be able to take
a Noise protocol off the shelf and get running quickly with good
defaults and easy interop with other libraries.

To address these different needs I'll suggest separating the "Noise
core" (what we currently have) from some "Noise conventions" which we
encourage people to adopt for ease-of-use and interop.

In particular:

 * For the Noise core we'd follow a suggestion from Jason and change
the prologue to be some arbitrary-length additional authenticated data
(cryptographically handled the same as the current prologue, but
generalized to remove concrete decisions about size and encoding).

https://moderncrypto.org/mail-archive/noise/2015/000212.html

 * There would be a Noise convention for length and version fields
that are encoded prior to every Noise message, so an encoded message
becomes:
 - 32-bit little-endian length of subsequent data
 - 8-bit version field, defaults to zero
 - Noise message, version field included in prologue

 * We'd also specify a padding convention, same as the previous Noise:
 - last 32-bits of a decrypted plaintext is little-endian encoding of
the number of the padding bytes added to the plaintext (not counting
the length field itself)


Presumably a good Noise library would give users access to the
length/type convention, and the padding convention, but also allow
users to disable them for raw access to the Noise core.

What do people think?

Trevor