Implements a key store system

This pull request adds a system whereby clients have their own unique key for encrypting the user details portion of a token. This allows for key revocation in the even a remote service is compromised, or is just no longer allowed to log clients into the CAS server.

The implemented key store is simply a JSON file residing on the system. This file contains an array of "key" objects. A key is simply a two property object with `name` and a `data` fields. The `name` field is the key used by a remote service to encrypt the user details portion of a token.

As hinted, this pull request changes the format of the token. The new token is

    {
      "generated": 1235623987,
      "api_key": "16_char_string",
      "credentials": "[base64 encoded encrypted string]"
    }

The `api_key` is the same as the `name` property of a key object. The decrypted `credentials` JSON object is the same as the original token object, minus the `generated` property:

    {
      "username": "auser",
      "firstname": "foo",
      "lastname": "bar",
      "email": "foobar@example.com"
    }

Note, I have not tested adding the module to a running CAS server. I did update the instructions on how to do so, and I believe they are correct, but I haven't tested that part yet. I did, however, add several unit tests to verify the functionality. Provided the module is added to the CAS server correctly, it should work as intended.