Switch to semantic versioning

Discussed here:

  http://lists.openstack.org/pipermail/openstack-dev/2013-March/006283.html

The date based 2013.1 version is likely to be disallowed by PEP426
when it is ratified and we'll be required to treat the date based
version as a "private version" and use 0.2013.1 as the official
version.

Also, I'm coming around to the idea of using semantic versioning
(i.e. x.y.z) and increasing the major number when removing any
deprecated APIs. Th is the trend that Python is following according to
a discussion on distutils-sig.

One consequence of using semantic versioning is that we'll be very
loathe to remove any deprecated APIs since it will mean a version bump
from 1.y.z to 2.y.z. That's probably not a bad thing.

With this versioning scheme, I figure we should start with 1.1.0
(2013.1-2012). We'll increase the micro number when we do release from
the stable branch and increase the minor number with every coordinated
OpenStack release.

Change-Id: Ibe033d37742b82dee5f42d9e3d6a0b51582bd3ce
Change the name of the project to oslo.config

Again discussed here:

  http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6283
  http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6138

The rationale is that the use of namespace packages is likely to
increase and there is apparently some consensus that the convention
should be to use period to separate the namespace package name from
the subpackage name - i.e. call it oslo.config. The zope.interface is
an example of this convention, but PasteDepoy is a counter-example.

Oslo is going to have a family of libraries, so it'd be much nicer if
they followed what the future Python convention is likely to be.

This is a disruptive change for packagers and the benefit isn't huge,
but pairing it with the also disruptive change to the versioning
scheme makes it somewhat more acceptable.

Change-Id: I63e96a8b48b166b07f1c8e79b6eaffb6234cc751