hdk shared secret api

[neonphog]

Summary

@thedavidmeister - Here's what I'm thinking for getting the shared secrets into lair, let me know your thoughts:

• Using unsized bytes for key ref so users can supply other references that make more sense in app-specific ways (e.g. prefixes like (my_key_type:[32 random bytes]). But we'll still auto-generate an identifier if they pass in None to either create or ingest.
• We provide:
  • x_salsa20_poly1305_shared_secret_create_random - generates a random shared secret
  • x_salsa20_poly1305_shared_secret_export - exports an existing shared secret encrypted as a box for a specific other agent
  • x_salsa20_poly1305_shared_secret_ingest - which can import shared secrets either exported via hdk or generated from some custom app-specific process.
• We've got a bit of a mix of verb-noun function names and noun-verb function names... I went with noun-verb, I prefer them in general because they then sort together lexicographically.

TODO:

• CHANGELOG(s) updated with appropriate info
• Just before pressing the merge button, ensure new entries to CHANGELOG(s) are still under the UNRELEASED heading