Encrypted Slatepack Metadata

[yeastplume]

Adds encrypted metadata to the slatepack definition, which works as follows:

• Encrypted metadata isn't serialized separately, it's rather prefixed to the slate payload on encrypt, and split off on decrypt.
• On encryption, the sender field is moved from the unencrypted header into the encrypted metadata field, and is moved back on decryption. This means that anyone using the struct only needs to worry about setting the sender field in one place.
• Recipients can be added to the Slatepack, but if the payload is not encrypted they won't be included in serialization (as they can only exist in the payload of an encrypted slate)

Also includes

• Slatepack function to add recipients
• Tests ensuring that SlatepackEncMetadata struct will continue to parse correctly when additional fields are added (similar to how the optional header fields work now)

[quentinlesceller]

Looking good 👍 Small comments here and there.

[j01tz]

This seems to implement the encrypted metadata fields as discussed in the RFC. The specific details like the 4 byte length and additional optional content flags will require an update to the RFC to keep details accurate and in sync.

To echo Quentin's point about versioning, in the RFC I have the first release as 0.1 and was planning for 1.0 in the final HF once we have finalized all of the details and are happy with long term support for the standard. It doesn't make a big difference though and want to go with whatever is consistent with other work- I can adjust the RFC if we want the first release to be 1.0.

I think we will likely need some more refining and thought needed around recipients field and how it would actually be used but is not critical to have this completely ironed out before the first release.

Otherwise looks good- I haven't manually verified all of the bit plumbing going on, but will get to it as we get into testing. Nice work getting this in, looking forward to testing exchanging some encrypted slatepacks this week 👍