aead: incremental encryption API

Though an incremental/"streaming" decryption API is unsafe as by design it must disclose unauthenticated plaintext candidates (which can allow an attacker to perpetrate CCAs), incremental encryption is both possible and safe.

We've had a few requests for incremental/"streaming" APIs:

• https://github.com/RustCrypto/traits/issues/62 requested "streaming" AAD specifically
• https://github.com/RustCrypto/AEADs/issues/497 and https://github.com/RustCrypto/AEADs/issues/556 requested "streaming" encryption

It seems like such an API would need to make ordering presumptions about how AAD and the input message are received, e.g. the first phase would stream AAD input, and the second phase would stream the input message. Such a construction should cover the most common AEAD modes, but wouldn't work for modes that put AAD at the end for whatever reason (can't think of any offhand).

I don't think it makes sense to support incremental/streaming AAD independently of also streaming the message (as originally requested in https://github.com/RustCrypto/traits/issues/62): if one is streamed, both should be streamed, though perhaps there could be a simplified way to avoid AAD if it isn't desired.

I would also suggest using the word "incremental" over "streaming" so as to avoid confusion with the STREAM construction implemented in aead::stream.

Start by reviewing the existing aead::stream API and the related requests in RustCrypto/traits#62, RustCrypto/AEADs#497, and #556. Determine and document the incremental AAD and message ordering assumptions, including how optional AAD is handled and which AEAD modes are supported. Done means a settled API design that is safe for incremental encryption without exposing unauthenticated plaintext.