Add split configuration support to the inventory

This patch adds the idea of a conf_d parameter to dynamic_inventory
and the rpc_user_config.yml and rpc_environment.yml files.

This enables the configuration to be split into a conf.d structure
to better manage large deployments and different independent parts
of the openstack cluster.

Swift is a good example, a swift cluster could stretch into 100s or
1000s of nodes, and rather then having all these nodes and swift
specific variables defined throughout rpc_user_config.yml. They
can all be defined in one yml file and dumped into the conf.d
directory.

A nice benefit of this is that if the user wants to use swift,
the configuration simply needs to dumped into this folder,
if not, remove it.

Further, swift variables are defined in global_overrides and then
in its own swift_hosts and swift-proxy_hosts sections, the conf_d
location allows all the configuration to appear together.

When updating the extra_configuration yaml files to the main config
object in python, the simple dict.update doesn't work as we want to
be able to define values for global_overrides that don't replace
the global_overrides dict in the python object but rather append to it.
This has been accomplished with a new helper method update_dict, which
recursively drills down and merges the configuration, allowing us to
be able to append to sub sections of the yaml in conf_d segments:

  global_overrides:
    swift:
      part_power: 8
      account:
        repl_number: 3
        min_part_hours: 1
      container:
        repl_number: 3
      storage_policies:
       - policy:
           name: gold
           index: 0
           repl_number: 3
           default: yes
       - policy:
           name: silver
           index: 1
           repl_number: 2
           deprecated: yes

From the swift point of view the benefit of this change now means we
can have a swift.yaml file that contains all the swift configuration
which will ease management. But I believe this can manage other areas
of RPC deployments depending on the size of the cloud being built.