Memo type, existing EncryptedCiphertext types for Sprout and Sapling

[dconnolly]

This is a nice isolated chunk that can get merged in first.

[hdevalence]

This is great! A few comments:

• I think it would be cleaner in the long run to move the Memo impl into note_encryption/memo.rs and pub use memo::Memo; inside of note_encryption.rs, so that we separate the module tree organization from the implementations, and potentially also to split out the tests into separate files.
• 500-byte arrays are big enough that we might want to use Box<[u8; 512]>, so that moving ownership of Memo, EncCiphertext, etc doesn't result in a bunch of stack memcpys.
• Using TryFrom rather than From seems like less of a sharp edge.

Non-blocking for this PR, looking at the part of the protocol spec you linked, there's a section about memo encodings at the top of page 73 that has four cases:

I wonder whether it makes sense to represent this in the Memo structure itself with something like

enum Memo {
    // encoded as 0xf6 0x00 ... 0x00
    NoMemo,
    // valid UTF-8, encoded with trailing 0x00 padding
    Utf8(String),
    // encoded as 0xf5 <data>
    Bytes(Box<[u8; 511]>),
    // everything else we can't parse + reserved
    Other(Box<[u8; 512]>),
}

and handle the parsing in the serialization implementations. This has the upside that users of the Memo field don't have to do any parsing to figure out what's in the memo, but has the downside that we don't have a way to bound the length of the string, and we need the string's length to be bounded so that ZcashSerialize is infallible. So I'm not sure if this quite works, and it definitely shouldn't block this PR, but it might be good to do something like that later?

[hdevalence]

Hmm, actually.... I wonder whether the ZcashSerialize/ZcashDeserialize impls for Memo will end up being used, since the plaintext isn't committed to the chain, so perhaps it would work to only have the ciphertexts be ZcashSerialize and for the Memo to not be. Then the encryption method or something would have to be fallible (e.g., failing on long messages), but the Memo itself could have a structured internal representation, or something?

[hdevalence]

Related: https://github.com/zcash/librustzcash/pull/177/files