Refactored how expires_in is returned to clients, it now represents the token TTL from the time the response is sent
According to Section 4.2.2 of the OAuth spec (http://tools.ietf.org/html/rfc6749#section-4.2.2):

expires_in
         RECOMMENDED.  The lifetime in seconds of the access token.  For
         example, the value "3600" denotes that the access token will
         expire in one hour from the time the response was generated.
         If omitted, the authorization server SHOULD provide the
         expiration time via other means or document the default value.

The current implementation returns the values of the `expires_in` fields on the token record, which is relative to
the time the token was generated.  This change switches to returning the expiration time relative to when the request
was made (since future requests could return the same token as long as it's not expired).
Merge remote-tracking branch 'applicake/master' into fix_token_expiration
Merge remote-tracking branch 'applicake/master' into fix_token_expiration
Udated test to provide expires_in_seconds on the mocked access_token, wrote comment explaining test behavior for 'expires_in'
Merge pull request #228 from centro/fix_token_expiration

Fix token response `expires_in` value to be relative to request time