"Helpers" is one of those terms like "utils" that means "we don't know
what belongs in this module and what doesn't," so let's get rid of it in
favor of a shorter name that better reflects the purpose of everything
in the module. This name nicely opposes to sql.core, which contains
everything we use for more general database interactions.

Change-Id: I65ed77bc597b66eaffe5126275366f8ae141524b

keystone.common.config is 1200+ lines of super dense, merge-conflict
prone, difficult to navigate, and finicky to maintain code. Let's follow
nova's lead and break it down into more manageable modules.

This patch creates a new Python package, keystone.conf, and moves all of
our configuration options into it, mirroring nova's nova.conf package.

There are a couple special modules in keystone.conf introduced here as
well:

- keystone.conf.__init__: This causes all of Keystone options to be
  registered on import, so consumers of keystone.conf don't have
  races with config initialization code while trying to use
  oslo_config.cfg.CONF directly (keystone.conf replaces all uses for
  oslo_config.cfg.CONF in keystone).

- keystone.conf.base: Keystone's [DEFAULT] group options. I'd prefer
  this to be called 'default.py', but I'm just copying nova's lead here.

- keystone.conf.opts: The entry point for oslo.config itself.

- keystone.conf.constants: There are a few constants (deprecation
  messages, default paths, etc) that are used by multiple configuration
  modules, so they need to live in a common place.

Change-Id: Ia3daffe3fef111b42de203762e966cd14d8927e2

This is the most basic way to move the federation migrations into
the keystone core migrations path. Check to see if the migration was
performed already via the extension and if so skip performing it again.

Change-Id: Id437bb68d281ee51e9a671591051c30c35f41bf0
Implements: bp move-extensions