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 branch 'fix_token_expiration' of github.com:centro/doorkeeper into feature/expires
Merge pull request #1 from crowdlab-uk/feature/expires

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):