network: allow <pf> together with <interface>/<address> in network status
    
    The function that parses the <forward> subelement of a network used to
    fail/log an error if the network definition contained both a <pf>
    element as well as at least one <interface> or <address> element. That
    check was present because the configuration of a network should have
    either one <pf>, one or more <interface>, or one or more <address>,
    but never combinations of multiple kinds.
    
    This caused a problem when libvirtd was restarted with a network
    already active - when a network with a <pf> element is started, the
    referenced PF (Physical Function of an SRIOV-capable network card) is
    checked for VFs (Virtual Functions), and the <forward> is filled in
    with a list of all VFs for that PF either in the form of their PCI
    addresses (a list of <address>) or their netdev names (a list of
    <interface>); the <pf> element is not removed though. When libvirtd is
    restarted, it parses the network status and finds both the original
    <pf> from the config, as well as the list of either <address> or
    <interface>, fails the parse, and the network is not added to the
    active list. This failure is often obscured because the network is
    marked as autostart so libvirt immediately restarts it.
    
    It seems odd to me that <interface> and <address> are stored in the
    same array rather than keeping two separate arrays, and having
    separate arrays would have made the check much simpler. However,
    changing to use two separate arrays would have required changes in
    more places, potentially creating more conflicts and (more
    importantly) more possible regressions in the event of a backport, so
    I chose to keep the existing data structure in order to localize the
    change.
    
    It appears that this problem has been in the code ever since support
    for <pf> was added (0.9.10), but until commit
    34cc3b2f106e296df5e64309620c79d16fd76c85 (first in libvirt 1.2.4)
    networks with interface pools were not properly marked as active on
    restart anyway, so there is no point in backporting this patch any
    further than that.