extension migrations

Allow each of the extensions to have their own
sql migration repository instead of mixing them into
the common repo.  db_sync must be called explicitly on the extension.

In the past, it was assumed that only migrations for backends backed in
sql would be run.  In practice, however, all of the migrations were run
every time.  The code has been modified to reflect this.

Adds parameter --extension to the cli for db_sync and db_version

to test out the migrations

bin/keystone-manage db_sync --extension example

will migrate to version 1 and

bin/keystone-manage db_sync --extension example 0

will migrate it back to 0

to check the version

bin/keystone-manage db_version --extension example

blueprint multiple-sql-migrate-repos

DocImpact

Change-Id: I6852d75bde6506c535fa3d74537e3c1bbd6578d8
Merge "extension migrations"
Fix select n+1 issue in keystone catalog

keystone.catalog.backends.sql.get_catalog() and get_v3_catalog() methods
generate N+1 select statements for each endpoint. Use sqlalchemy's
eager load to generate single select statement instead of generating N+1
select statents for each endpoint.

Given change does not modify DB schema and is runtime-only, since it's a
one-to-many relationship.

Change-Id: Ia72b8603fc13f01696771f6116b320364bd50f51
Fixes: bug #1206725
Merge "Fix select n+1 issue in keystone catalog"