One of the original ideas behind allowing a <virtualport> in an
interface definition as well as in the <network> definition *and*one
or more <portgroup>s within the network, was that guest-specific
parameteres (like instanceid and interfaceid) could be given in the
interface's virtualport, and more general things (portid, managerid,
etc) could be given in the network and/or portgroup, with all the bits
brought together at guest startup time and combined into a single
virtualport to be used by the guest. This was somehow overlooked in
the implementation, though - it simply picks the "most specific"
virtualport, and uses the entire thing, with no attempt to merge in
details from the others.

This patch uses virNetDevVPortProfileMerge3() to combine the three
possible virtualports into one, then uses
virNetDevVPortProfileCheck*() to verify that the resulting virtualport
type is appropriate for the type of network, and that all the required
attributes for that type are present.

An example of usage is this: assuming a <network> definitions on host
ABC of:

  <network>
    <name>testA</name>
    ...
    <virtualport type='openvswitch'/>
    ...
    <portgroup name='engineering'>
      <virtualport>
        <parameters profileid='eng'/>
      </virtualport>
    </portgroup>
    <portgroup name='sales'>
      <virtualport>
        <parameters profileid='sales'/>
      </virtualport>
    </portgroup>
  </network>

and the same <network> on host DEF of:

  <network>
    <name>testA</name>
    ...
    <virtualport type='802.1Qbg'>
      <parameters typeid="1193047" typeidversion="2"/>
    </virtualport>
    ...
    <portgroup name='engineering'>
      <virtualport>
        <parameters managerid="11"/>
      </virtualport>
    </portgroup>
    <portgroup name='sales'>
      <virtualport>
        <parameters managerid="55"/>
      </virtualport>
    </portgroup>
  </network>

and a guest <interface> definition of:

  <interface type='network'>
    <source network='testA' portgroup='sales'/>
    <virtualport>
      <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                  interfaceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"\>
    </virtualport>
    ...
  </interface>

If the guest was started on host ABC, the <virtualport> used would be:

  <virtualport type='openvswitch'>
    <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'
                profileid='sales'/>
  </virtualport>

but if that guest was started on host DEF, the <virtualport> would be:

    <virtualport type='802.1Qbg'>
      <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                  typeid="1193047" typeidversion="2"
                  managerid="55"/>
    </virtualport>

Additionally, if none of the involved <virtualport>s had a specified type
(this includes cases where no virtualport is given at all),