Adds storage driver interface, tests, and three basic implementations

Re-opening of #630 with the new orphan next-generation branch.

@dmp42 @wking @bacongobbler @noxiouz 
On Mon, Nov 03, 2014 at 07:05:04PM -0800, Stephen Day wrote:
> Without introducing problems with missing or inconsistent directory
> listings, the variation in the drivers makes getting a reentrant
> interface right problematic.

Using either a marker string [1] or an opaque marker type [2] seems to
support all proposed backends.  With the marker stored in the
registry, the storage backend doesn't need to keep track of open list
calls, so a reentrant interface is easy.  Or am I missing something?

> The other issue here is that whether or not these calls are
> reentrant, you end up allocating the same amount of memory. Thus,
> large directories will cause latency in registry requests no matter
> what.

How so?  ZRANGEBYSCORE is O(log(N)+M) with N being the number of
elements in the sorted set and M the number of elements being
returned.  That scales pretty well.  More importantly, it lets you
start streaming results from the registry to the client before you've
finished listing the whole directory.

> We can always revisit this in the future if we've made the wrong
> decision today.

True, but we're already having trouble with the current layout (#614).

[1]: https://github.com/docker/docker-registry/pull/643/files#r19771475
[2]: https://github.com/docker/docker-registry/pull/643/files#r19775666