WIP: Bugfix Get File wrong content type **Needs reviews for me to proceed**

- Fixes bug in the Get File end-point where the response header contained 'text/html;utf-8' instead of 'application/binary' or even 'application/octet-datastream'
- Fixes bug in blockstoragedriver's create_blocks_generator whereby the auth token was not propagated
- Sets the content length when setting the content-type to 'application/binary'
- Removes the Auth Token check from the ProjectIdHook
- Adds new AuthTokenHook
- Adds test coverage for the AuthTokenHook in the root controller test
- Makes explicit the test for the ProjectIdHook in the root controller test

Note: pecan.Response object is really the WebOb.response.Response object. See http://webob.readthedocs.org/en/latest/modules/webob.html for details. It has some funky behaviour regarding the content-type information. Specifically setting content-type to "application/binary" will just append the existing content-type information, so you still get "application/binary;utf-8"; while setting it to "application/binary;" will make it drop anything and only set it to "application/binary;".  This seems backwards, but is how it works.

Note: MongoDB is exhibiting some unreliable behaviour with respect to getting the file size. This results in one of two scenarios being presented for the coverage. Scenario 1 only one line is not covered; while Scenarios 2 has two groups with 11 and 43 lines not covered respectively. The failing line is 265 of the test_sqlite_storage_driver.py. Py27 seems to only exhibit Scenarios 1. Py34 and PyPy exhibit both. Haven't tested Py33.  Thinking its my MongoDB queries I tested this with https://gist.github.com/BenjamenMeyer/1957bb411dfd9b38d850 but it does not exhibit the behaviour; it primarily only removes the block information.
@raxyu  - I added that line specifically because of having problems with Pecan _not_ setting the content-length when the content-type was set to "application/binary".