Adds versioning for out-of-process storage driver

The registry currently only accepts storage driver versions with the
same major version and an equal or lower minor version as its own
current storage driver api version, but this may be changed in the
future if we decide to implement specific version cross-compatibility.
Expects storage driver executables to be of the form registry-storage-name

Moves main packages to sub-packages of the individual storage drivers
Merge pull request #685 from BrianBland/storagedriver

Expects storage driver executables to be of the form registry-storage-<name>
Renames ResumeWritePosition to CurrentSize in storage driver api
Merge pull request #699 from BrianBland/storagedriver-api-rename

Renames ResumeWritePosition to CurrentSize in storage driver api
Merge pull request #686 from BrianBland/storagedriver-versioning

Adds versioning for out-of-process storage driver
Initial V2 API Router Implementation

This commit includes the initial API router, based on gorilla mux and a test
suite ensuring the expected variables are extracted. Currently unexported, the
structure here will likely change as this definition will be shared with the
API client.
Merge pull request #701 from stevvooe/initial-api-routes

Initial V2 API Router Implementation
Initial open-design proposal
Merge pull request #642 from docker/init

Initial open-design proposal
Initial implementation of API errors data structure
Allow Errors to be an error itself

This has Errors implement the error interface, allowing it to pose as an error
itself. Use of this in the server may be minimal, for now, but it's useful for
passing around opaque client errors.

A method, PushErr, has also been add to allow arbitrary errors to be passed
into the Errors list. This keeps the errors list flexible, allowing the app to
collect and errors before we have codes properly mapped.
Merge pull request #711 from stevvooe/errors-marshaling

Initial implementation of API errors data structure
Clearer names for layer upload routes
Carve out initial application structure

This changeset defines the application structure to be used for the http side
of the new registry. The main components are the App and Context structs. The
App context is instance global and manages global configuration and resources.
Context contains request-specific resources that may be created as a by-product
of an in-flight request.

To latently construct per-request handlers and leverage gorilla/mux, a dispatch
structure has been propped up next to the main handler flow. Without this, a
router and all handlers need to be constructed on every request. By
constructing handlers on each request, we ensure thread isolation and can
carefully control the security context of in-flight requests. There are unit
tests covering this functionality.
Merge pull request #712 from stevvooe/application-structure

Carve out initial application structure
Test drone