pci: properly handle out-of-order SRIOV virtual functions
    
    This resolves:
    
      https://bugzilla.redhat.com/show_bug.cgi?id=1025397
    
    When virPCIGetVirtualFunctions created the list of an SRIOV Physical
    Function's (PF) Virtual Functions (VF), it had assumed that the order
    of "virtfn*" links returned by readdir() from the PF's sysfs directory
    was already in the correct order. Experience has shown that this is
    not always the case - it can be in alphabetical order (which would
    e.g. place virtfn11 before virtfn2) or even some seemingly random
    order (see the example in the bugzilla report)
    
    This results in 1) incorrect assumptions made by consumers of the
    output of the virt_functions list of virsh nodedev-dumpxml, and 2)
    setting MAC address and vlan tag on the wrong VF (since libvirt uses
    netlink to set mac address and vlan tag, netlink requires the VF#, and
    the function virPCIGetVirtualFunctionIndex() returns the wrong index
    due to the improperly ordered VF list).
    
    The solution provided by this patch is for virPCIGetVirtualFunctions
    to no longer scan the entire device directory in its natural order,
    but instead to check for links individually by name "virtfn%d" where
    %d starts at 0 and increases with each success. Since VFs are created
    contiguously by the kernel, this will guarantee that all VFs are
    found, and placed in the arry in the correct order.
    
    One note of use to the uninitiated is that VIR_APPEND_ELEMENT always
    either increments *num_virtual_functions or fails, so no this isn't an
    endless loop.
    
    (NB: the SRIOV_* defines at the top of virpci.c were removed
    because they are unnecessary and/or not used.)