Add Storage Policy Support

The basic idea here is to replace the use of a single object ring in the Application
class with a collection of object rings. The collection includes not only the Ring
object itself but the policy name assocaited with it, the filename for the .gz and
any other meta data associated with the policy that may be needed.  When containers
are created, a policy (thus a specific obj ring) is selected allowing apps to
specify policy at container creation time and leverage policies simply by using
different containers for object operations.

The policy collection is based off of info in the swift.conf file parsed at wsgi
application init time. The format of the sections in the .conf file is covered
below and accessed via get__policies() that has all of the info except
for the Ring addresses; the rings are instantiated "just in time" when the App
method get_object_ring() is inoked for the first time per policy. There is basic
error handling in both the conf file parser as well as the accessor functions to
assure the conf file is formed correctly.

swift.conf format:

	[storage-policy:0]
	name = chicken

	[storage-policy:1]
	name = turkey
	default = yes

With the above format:

- policy 0 will always be used for access to existing containers w/o the policy specified.
The ring name for polic 0 is always 'object' assuring backwards compatiblity.  The parser
will always create a policy 0 even if not specified
- the policy with 'default=yes' is the one used for new container creation and allows the
admin to specify which policy is used without forcing the application to add the metadata.
- in the future new elements can be added such as 'ec-scheme' which would imply that the
associated ring is built for erasure code and includes some ec scheme parameters.
A policy w/o any other tag like this implies replication using where the # of copies is
determined by how the ring was built

This commit focuses only on the Proxy server (storage node services using the obj
rings will be next) and the unit test framework changes and new unit tests.

Ring selection is done at public entry points based on container metadata. If the
container has the metadata X-Storage-Policy and there is a match with the policy
name provided and one parsed from swift.conf, that ring will be used. If not then
decisions are made per description of swift.conf sections above.  Note that internally
there is a policy index that is used in conjunction with X-Storage-Policy that enables
the cluster admin to both support backwards compatibility as well as choose the
default that is most applicable for their cluster.  The internal metadata stored in
containers is called X-Storage-Policy-Index.

The container metadata policy cannot be changed, if an attempt is made to change it a c
onflict error will be returned. An attempt to create a container with a policy not defined
results in a bad reqeust error.  Migrating data from one policy to another means copying it
from one container to another manually.

The following highlights the major changes in this commit:

* swift.conf file parser support for storage policies (new storage_policy.py)
* container update to support immutable storage policy metadata
* a few misc function parm changes to enable passing of ring info
* use of ring based on container metadata in objController public functions
* large number of changes to unit test framework to support multiple rings
but no new capabilities specifically geared at testing multiple rings
* unit tests covering all new functinality

Storage Node services to support Storage Polciies are not included here.

Change-Id: I53bcad1dc724596c5c4ec8a30d5cf50ebe7f1b7d
Implements:  blueprint ec-proxy-work