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.