encrypted UDP

## What?
Provide encrypted UDP support.
No need for asymmetric cryptography & certificate. "Only" symmetrically encrypt UDP packets using a per-stream shared-secret (possibly derived from the write token) with a stream-based encryption algorithm.

## Why?
UDP is very important in many cases due to it "send-and-forget" nature. No handshake, no wait/timeout.
For being unencrypted it's not suitable in scenarios where logs have to move outside a datacenter.
DTLS, as any handshake-based protocol, implies the client could bug/timeout if the server isn't online what is often less desirable than loosing logs entries.

A state-less symmetric encryption could solve this.

## Example:
On server-side, that means creating a `UdpCrypto` transport class like:
https://github.com/Graylog2/graylog2-server/blob/20ab7325eb82ec09c08ece0433e183412f32a05d/graylog2-server/src/main/java/org/graylog2/inputs/transports/UdpTransport.java

On the client, using the secret token as a key, it would be fairly easy to just [pipe client and server]
(https://gist.github.com/leonklingele/d5bd28ee51a4b8e49baa) into `openssl enc -aes-256-gcm -k $SECRET -e`.

## Possible issue: Multiple streams
The `netcat`-client side is trivial.
But since server's socket listens to multiple streams, a cleartext "stream" id, distinct from the write token, may have to be prepended to packet, in cleartext to allow stream-identification by the server then allowing decryption using the adequate shared-secret.

## Possible issue: Stream ID reply + wrong encryption key.
The decrypted payload must be checked. AES GCM provides built-in authentication tag mechanism to ensure decrypted content consistency. The tag could be the write-token.

## Possible issue: Packet replay
Nothing the client can do against this (without modifying payloads).