Routes and additional behavior for handling private repositories

# Private repositories: technical specifications
## Objectives
* Layers should only be available to their owner
* Public images api should stay the same
* API should stay simple and expressive

## Changes to storage layer
* When creating a private repository, or setting a repository as private, a metafile `_private` will be added under `BUCKET/repositories/<repo-name>/` (along with `_index_images` and `_images_list`)

## Changes to exposed API
* Public image layers are still available under `/v1/images/<image-id>/layer`
    * When accessing a layer in this fashion, we should now use the repository info contained in the token to ensure it is not private.
    * If a private layer is accessed in this fashion, the API response should have a 404 status code.
* Private images are accessible under `/v1/private_images/<image-id>/layer` (only to owner). This makes it easy to blacklist the routes on CDNs and caches.
* Same for JSON metadata.
* Public can be switched to private and vice-versa by hitting PUT `/v1/repositories/<repo>/access` with body:
    * `{ “access”: “private” }`  and 
    * `{ “access”: “public” }`
respectively. I expect these routes to be accessed by the index using privileged access.
* Access level can be retrieved by hitting GET `/v1/repositories/<repo>/access`. Useful for client implementations to figure out which endpoint to hit for JSON / layers

## Changes to authorization
* Token auth will allow us to defer to index authorization just like before.
* The token check should now differentiate authentication and authorization errors, and the API response should have the appropriate status code (401 or 403)

*Note: in the original design discussion I had with Sam, we were considering including repository info in the private images URL. IIRC this consideration stemmed from the idea that we would have to handle authorization in the registry, which is no longer true*