More flexible crypto config

With the protocol supporting negotiable cipher suites, some additional changes to support a more flexible crypto config seem like they could be useful.

Motivations:

There may be situations where:

• A dependent project wishes to link with a specific crypto library (ex. libsodium) that does not offer AES-GCM on all systems (possibly depending on processor architecture / extensions).
• Additional ciphers (like the commented-out k_ESteamNetworkingSocketsCipher_CHACHA20_POLY1305) with different performance characteristics or system / crypto library compatibility are desired.
• A dependent project is fine with advertising "best-effort" encryption, which falls back to advertising "null cipher"-only if a particular system + crypto library combination cannot support any.

Additionally (although not considered in-scope at this time, but the work in this should help):

• A dependent project may not wish to link GameNetworkingSockets with any of its supported crypto libraries (and may be fine with GameNetworkingSockets itself not implementing encryption at all, perhaps because it already handles this).

Tasks (WIP):

• AES-GCM runtime availability check
  (#197)
• Advertise / initialize AES_GCM cipher only if supported
  (#197)
• Support building with libsodium on non-x86/x86_64 CPUs (with an appropriate default warning that this means there will not be AES-GCM support).
• Add support for k_ESteamNetworkingSocketsCipher_CHACHA20_POLY1305. (@fletcherdvalve: Should this be the
  IETF variant of ChaCha20-Poly1305?)

The issue names no files, tests, or entry points. Start by reading issue #197 and the listed motivation and WIP tasks; done would require resolving the scope and completing the runtime availability, cipher advertisement and initialization, non-x86 libsodium, and ChaCha20-Poly1305 items.