feature: gossip encryption key rotation

Since Serf supports symmetric key rotation for gossip messages, Consul can leverage this to allow key rotation for both the LAN and WAN gossip pools.

Because of the multiple gossip pools and a few other semantic differences between Serf and Consul, there are a few things to note about this implementation:

* The command is `consul keyring` to avoid confusion with TLS keys or KV keys.
* For operational simplicity, both LAN and WAN keyrings are modified / queried in the same command run for all keyring-related commands.
* Only server nodes are allowed to query or modify any keyrings. This avoids ambiguity in running `consul keyring` on a server vs. a client.
* Both LAN and WAN keyrings are persisted separately in consul's data-dir.
* At agent start, if keyring files exist in consul's data directory, they will be automatically loaded and updated if keys change.
* The `-encrypt` argument still works with unmodified behavior

Some examples of the feature in action in a cluster with one server and one client are in [this gist](https://gist.github.com/ryanuber/435f14e225be7cee12c7).

I've still got a few more tests and docs to write, but would like feedback on the overall flow of how this is working in its current form.

 Related to #246 
Agreed - Done! The main challenge was that any `inmemCodec` response will be replaced by its `WriteResponse()` method, which is why the `structs.CompoundResponse` also provides a `New()` method. This way, within `globalRPC`, we can get an independent response object for each RPC call, then just pass a reference of that to the existing `forward()` method.