Adarnauth-esi

This release adds support for initializing a client from a spec file shipped with your project by passing its path as the `spec_file` kwarg. The "old" way of specifying resource versions is depreciated.

Additionally this release adds caching of get requests according to the `Expires` HTTP header. This can be disabled by setting the `ESI_CACHE_RESPONSE` setting to `False`.

This release changes how SSO returns are handled.

Previously every return would result in a new token. However on the EVE site, under the Third Party Applications sections, additional entries are not consistently created when tokens are returned with duplicate scopes (as in, if there was already a token granted to the application with the same scopes, another SSO request would not result in a new entry BUT it would result in a new token in the database).

Now tokens returned to us with scopes we already have (matching exactly, not inclusively) will not result in a new token in the database, but will be used to update existing database entries and the existing one will be returned to the view. This better matches the end-user experience. To emulate the old one-token-per-callback behaviour set `ESI_ALWAYS_CREATE_TOKEN` to `True`.

Also per 1 you can pass the code to the manager instead of the request so it can work in an API environment more easily.

This prevents Spec construction without an initialized RequestsClient, which would occur using the factory without a token or datasource provided.

Properly catches OAuth-related errors and ignores connection errors. Tokens will not be deleted if the connection to the server is bad.

Clients can now be initialized with mixed resource versions. Specify the desired version as a kwarg of the form `Universe='v1'` through tokens or the factory.

Token.get_esi_client` now accepts the `version` kwarg and passes it to the factory.