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.
README.md: Document _env: syntax defaults

Catch the docs up with 7762af1 (Added support for environment variable
default value, 2013-12-09).
run.sh: Remove --debug argument

This doesn't do anything constructive in Gunicorn v18.0, and having it
around just interferes with --preload [1].

[1]: https://github.com/benoitc/gunicorn/pull/701
run.sh: Add '$GUNICORN_OPTS "$@"' to gunicorn invocation

This allows users to add custom arguments via the command line ($@) or
environment ($GUNICORN_OPTS), which is useful if you want to --preload
(or tweak some other setting) without editing your config file.
search: Use SQLAlchemy as a search-index backend

This avoids storing search-index state in the local process (as the
previous Python-dict-based implementation did).  Multiple registry
processes (e.g. gunicorn workers) can now use the same search-index
database and stay in sync with each other.
index: Factor out the SQLAlchemy Index into flexible backends

Make it easy to add alternative backends for the search endpoint.
I've added a 'search_backend' config and renamed the 'search_index' to
'search_sqlalchemy_database' to avoid colliding with other backends.

I've called the SQLAlchemy module 'db' so we can distinguish between
the global sqlalchemy package and our SQLAlchemy-based index module
without using the absolute_import future [1,2,3,4].

[1]: https://docs.python.org/2/library/__future__.html
[2]: http://legacy.python.org/dev/peps/pep-0328/
[3]: https://github.com/dotcloud/docker-registry/pull/247#discussion_r11360344
[4]: https://github.com/dotcloud/docker-registry/pull/247#issuecomment-40434561

Reported-by: Lee Trout <ltrout@newsinc.com>
index: Expand load() to handle arbitrary module names

It would be nice if users could point to their own index
implementations if a suitable backend is not supplied by
docker-registry.  This commit adds support for loading Index
implementations from arbitrary modules.

Reported-by: Lee Trout <ltrout@newsinc.com>
Merge pull request #247 from wking/search-index

Flesh out repository deletion and add basic search indexing