tags: Factor get_tags out of the _get_tags endpoint

Gettings a nicely-parsed list of tags is useful internally, so pull
the tag-listing logic out into it's own function.  The decorated
endpoint behind GET /v1/repositories/<path:repository>/tags is *not*
useful internally, so prefix that function with an underscore.

To convert the get_tags iterator to a dictionary, I've used a dict
comprehension [1], which landed in Python 2.7 and 3.0.  I couldn't
find any docs on docker-registry's minimal supported Python version,
so I imagine compatibility with ancient Pythons is not high on the
agenda.

[1]: http://www.python.org/dev/peps/pep-0274/
tags: Factor delete_tag out of the _delete_tag endpoint

Deleting a tag (and raising the associated signal) is useful
internally, so pull the tag-deleting logic out into it's own function.
The decorated endpoint behind
DELETE /v1/repositories/<path:repository>/tags/<tag> is *not* useful
internally, so prefix that function with an underscore.
storage: Add Storage.repository_path

Besides factoring out a bunch of repetitive

  {self.repositories}/{namespace}/{repository}

construction, this gives us a path to recursively remove when we want
to delete a repository.
signals: Add repository-* signals

These aren't wired up yet; I'll do that in subsequent commits.
index: Trigger repository-created and repository-updated signals

Passing in the parsed JSON image data (ids and checksums).
index: Move delete_repository over from the tags module

The rename from

  DELETE /v1/repositories/<namespace>/<path:repository>/

(which matches the spec [1]) to

  DELETE /v1/repositories/<namespace>/<path:repository>/tags

(not in the spec) happened in 1026a87 (renaming DELETE call on a
repos, 2013-06-26), but the motivation behind the rename is unclear.
I'm also not sure why a delete_repository function is in the
registry.tags module (which already has the expected delete_tag
method).

This commit restores the original URL, shifts the function to the
index module, triggers tag-deleted signals for each tag, removes the
remaining repository data en masse, and triggers the
repository-deleted signal.  It doesn't remove referenced images,
because those images might be required by other repositories.  We'd
want some sort of refcounting (number of repositories/tags requiring
this image) to decide when image-removal was allowed.
search: Stub out a preliminary search index

This implements the

  GET /v1/search

endpoint using a simple JSON object for storage and a global Python
dict for live access.  That's not going to scale well for large
registries, but it's a start.  Benefits of this approach:

* We automatically support all the existing storage backends.
* The in-memory Python dict gives fast read-only access.

Drawbacks to this approach:

* Searches iterate over all key/value pairs (there's no precompiled
  index), so they'll be slow if you have tons of repositories.
* We write the whole index to the storage backend whenever a
  repository is created, updated, or deleted.
* If you have multiple registries sharing the same storage backend
  (e.g. gunicorn workers), your in-memory Python indexes will go
  out-of-sync, and may end up clobbering changes that other registries
  made to the stored index.

So this is basically a proof-of-concept for small registries.  A more
serious implementation would use an external SQL database to overcome
all of these limitations.  That should be easy to add later; for now
I'm focusing on getting the internal logic right.  Slotting in a
better backend later should be easy.

Because the search index code is only bound to registry.index by
signals, I've moved it into it's own registry.search module.  I added
a commented-out:

  #index = Index()

in the global-declaration section of the new module, to remind folks
that we would be creating a global 'index' object.  We can't actually
declare the global at that point though, because the Index class
hasn't been defined yet.

There's a version stamp in the saved index, and a missing index file
counts as v0, so folks who have been running earlier versions of
docker-registry will have their index built automatically the next
time they start the app.