19: Allow for a custom controller via @cournape

PR: https://github.com/ionrock/cachecontrol/pull/19
Example usage: https://gist.github.com/cournape/10432466
Use explicit relative imports
Merge pull request #20 from dstufft/relative-imports

Use explicit relative imports
Use sha224 instead of md5 to key the FileCache

MD5 is vulnerable to collision attacks which it may be possible
to use to attack a project using CacheControl. There are no
known theoretical or practical attacks against the sha-2 family of
hash functions so use one of them instead. sha224 is selected due
to the smaller digest size which will be less likely to hit edge
cases in filename sizes.
Merge pull request #21 from dstufft/use-sha-2

Use sha224 instead of md5 to key the FileCache

Note: This does raise the size from 32 to 56 characters. That is not a huge change, but in case it is, just subclass the FileCache and override the hashing as needed.
Use os.open to ensure that files for the cache have correct perms

The previous file handling code suffered from a few issues.

1. It would only create the leaf directory if it didn't exist but
   would error if any parent directories didn't exist. This will
   use os.makedirs to create anything needed.
2. Directories created by FileCache uses the default umask, instead
   we'll make this configurable and make it default to 0700 which
   will prevent any access from anyone but the user who owns the
   process.
3. Files created by FileCache use the default umask, instead we'll
   make this configurable and make it defalt to 0600 so only the
   user who owns the process can read/write them.
4. Following the cache file mode bits above, we'll also ensure that
   we create the files securely to prevent against symlink attacks
   or someone dropping a file with bad permissions before we open
   it.
Cache https as well as http by default
Merge pull request #23 from dstufft/cache-https

Cache https as well as http by default
Merge pull request #22 from dstufft/improved-file-handling

Use os.open to ensure that files for the cache have correct perms
Serialize the in memory cache to Pickle as well

This is done so that the in memory cache and the file/redis cache
will have the same behavior.
Cache the urllib3 HTTPResponse instead of the requests Response

Enables the use of requests.models.Response().raw by caching the
raw urllib3 HTTPResponse instead of the requests Response. We can
then construct a new Response on each request. This will also
enable things like resp.encoding and the future resp.content_encoding
to work correctly.

Some Notes:
  * Vary headers are currently broken because what we cache no longer
    has access to the request that made it.
  * This is backwards incompatible with the current cache handling
    code, that should be gracefully handled.
  * All requests, streaming or not, are still consumed immediately and
    are now replaced by a io.BytesIO backed HTTPResponse.
Do not monkeypatch requests.model.Response to enable pickle

CacheControl no longer attempts to pickle a requests.model.Response
object so we no longer care if it can be.
Gracefully handle the case where an old object is in the cache
Handle Vary headers

This keeps the existing behavior where a mismatch on the Vary headers
simply acts as a cache miss rather than making it possible to store
multiple responses for different sets of Vary headers. This includes
a change to the logic to properly handle the '*' value in a Vary
header.
Refactor Serialization

* Handles the conversion of Python values to pickle files in one
  location
* Properly supports versioned cache entries
Correct the tests for the new implementation
Make the test server work correctly on Python 3.x
Merge pull request #24 from dstufft/cache-raw-responses

Cache raw response instead of requests Response
Lazily cache the response once it has been naturally consumed
Merge pull request #25 from dstufft/dont-immediately-consume-response

Lazily cache the response once it has been naturally consumed