Make cfg group names case insensitive

Nova uses lowercase group names e.g.

 [baremetal]
 [cells]
 [conductor]
 ..

whereas Quantum uses lots of uppercase group names:

 [AGENT]
 [DATABASE]
 [DRIVER]
 ...

*sigh*

This thread brought the issue up: http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6309

One option is to make group names case insensitive but, even then, we probably also want the sample configuration files for all projects to consistently use lower or upper case. IOW, we should move Quantum to use lowercase group names :)

Here's a proposal:

  - log a deprecation warning if a project registers a group name that is not all lowercase before normalizing it to lowercase

  - in ConfigOpts getattr/getitem, just normalize the group name to lowercase and log a deprecation warning if it's a valid group

  - change Quantum's code to register and reference the groups in lower case

  - change Quantum's sample config files to use lowercase section names

That way, Havana will be using all-lowercase but Grizzly config files will still work without any warnings being printed

Other compat issues to think about:

 - if you're using Grizzly and you update to a newer version of oslo.config, you'll get a bunch of new warnings

 - if you're using CLI options with a group, it'll break - e.g. if you registered a 'FOO' group and a 'bar' CLI option, then the CLI argument would have been --FOO-bar. I don't know of anyone doing that and I think it's highly unlikely anyone would have done it.

I think we should continue using [DEFAULT] as the default section since that's what ConfigParser does

---

In the end, the plan became ...

The basic goal here is that we want to support the legacy use of group names like DATABASE in config files

That means:

1) if the API user registers a group called 'database', then we want to support reading values for the group from both database or DATABASE

This is purely about support for legacy group names in config files.

2) when the API user registers a group called 'database', then CONF.database should be how to reference it. When they register a group called 'DATABASE', then CONF.DATABASE should be how the reference it.

This ensures we're not making an incompatible API change - i.e. quantum's code will continue working and they only need to do s/CONF.DATABASE/CONF.database/ when they switch to oslo's DB code

3) the behaviour of [DEFAULT] should be unchanged so that users don't start switching to [default] and breaking existing tools

4) a deprecation warning to users/admins (i.e. a "you should fix your config file" warning) could *perhaps* be useful ... but it would need to be a one-time warning at startup per-file, not a warning every time a config value is accessed

We can live without this, though - we're not going to ever remove this case normalization semantics, so we don't need to be too active about getting users to switch to lowercase groups