Add support for OVS l2 agent in XS/XCP domU.

 * Config doc: http://wiki.openstack.org/QuantumDevstackOvsXcp

 * The Open vSwitch agent needs to be deployed on domU but
   interact with a dom0 bridge.
 * Add a root wrapper and associated XenAPI plugin to allow the
   agent to execute networking commands against dom0 from domU.
 * Update ovs_lib mac address discovery to use ip_lib to
   ensure that discovery works even for bridges not local to
   the agent (i.e. dom0 bridges).  A bridge configured with
   a dom0 root wrapper will execute ip link on dom0.
 * Update ip_lib to use a root helper by default to ensure that
   the 'ip' command will execute on dom0.
 * Remove obselete rpm spec and installer for dom0 agent.
 * Credit where credit is due - the XenAPI plugin and its
   packaging were largely copied from nova.
 * Supports blueprint xenapi-ovs

Change-Id: I7795446ee1267712c896f5cb3401f84fb1763ce7
Add support for DHCP agent in XS/XCP compute domU.

 * Config doc: http://wiki.openstack.org/QuantumDevstackOvsXcp

 * For a single-node devstack configuration, the DHCP agent will
   to run in the compute domU, which means DHCP servers need to attach to
   ports on an integration bridge in domU.  For DHCP service to be
   available to VM's, the dom0 and domU integration bridges need to be
   joined via a common interface and traffic between the two bridges
   trunked, and DHCP ports on the domU bridge need to be tagged with the
   appropriate local vlan.
 * Two changes are implied by this use-case:
   1. The OVS agent, which is responsible for tagging ports with the
      local vlan associated with the port's network, needs to tag ports
      on both the dom0 and domU integration bridges.  Since the agent
      keeps local vlan state in memory, running more than one agent
      would require a state-sharing mechanism, so this implementation
      chose the simpler path of relying on a single agent to interact
      with both the dom0 and domU bridges.  The major change was
      updating port-handling methods to be passed the bridge associated
      with a port, rather than presuming a default bridge.
   2. The OVS agent needs to ignore the interface between the dom0 and
      domU bridges.  The interface is not known to Quantum and the agent
      would put the associated port on the 'dead vlan', effectively
      cutting off communication between the bridges.  This
      implementation changes the agent to ignore ports on the dom0
      bridge that have mac addresses used by interfaces in domU.
 * Supports blueprint xenapi-ovs

Change-Id: Id707eaba60c2ed2e9d72eb6791a8a6aa8378c9b8
Fix get_port_macs

Change-Id: Idbc083389e97b5b872ce0e2a52ec8e3905d506ff