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