driver: Move tag iteration to Base.tags

From docker_registry.tags.get_tags.  Centralizing another abstraction
method helps hide the current nested filesystem implementation from
the coming upgrade methods.
driver: Add Base.image_path

Besides factoring out a bunch of repetitive

  {self.images}/{image_id}

construction, this gives us a path to recursively remove when we want
to delete an image.  Modeled after ab3805a5 (storage: Add
Storage.repository_path, 2014-02-12).
tags: Add image refcounting, so we can cleanup orphans

Before this commit there was no way to remove images that were no
longer needed by any tags.  This commit adds a persistent list of
references for each image, with both the depending image id and the
namespace, repository, and tag.  When we delete a tag, we traverse
it's ancestors removing any obsolete references and any images that
are no longer referenced.

This is more complicated than just having a refcount number, but also
more resilient.  For example, someone will eventually have a power
outage after removing a tag while the refcounts were still being
adjusted.  By keeping the references themselves in a list, it's easy
to check for stale references and remove them.  If it turns out that
the removal checks are too slow, it would be easy to make them more
optimistic (e.g. passing the descendant image and tags that we expect
to remove down the _remove_references stack and removing them instead
of checking all listed references for all ancestors).
driver: Version the storage format and add upgrade hooks

The upgrade from storage v0.0 to storage v0.1 just adds tag references
and cleans up unreferenced images.  I think all the storage subclasses
are too tightly bound to the file-based structure layed out in
driver.Base.  It would be nice is we exposed an API closer to the web
API (add a tag, get a tag, remove a tag, add a layer, get a layer,
remove a layer, ...), and left the internal details completely up to
the driver.  Of course, the file-like handling the the current Base
class could be a FileStorage utility for easy subclassing, but it
feels wrong to bake it into Base.  If we do pull it out, we'd want to
version both the Base API used by storage consumers.  We'd leave it up
to the implementations (like FileStorage) to version the backing data
store they used to provide the Base API:

  registry core <--(Base API)--> storage driver <--> backing store

Base.version and the version checks in Base._check_version allow the
storage driver to manage the backing store, and are independent of the
Base API used by the core.

In any case, the data in the backing store persists between software
upgrades, so we need *some* way to manage it as we polish the
persistent format.
driver: Make Base._image_path private

This is part of the internal backing-store interface, and isn't part
of the public Base API.