bins: warn if PCI devices have non-zero functions, but no function zero?

@papertigers tripped over this earlier: here's the important parts of the propolis-standalone config:

[main]
boot_order = ["block01"]

# [block_dev.alpine_iso]
# type = "file"
# path = "/rpool/propolis-dev/alpine-virt-3.22.2-x86_64.iso"

[block_dev.alpine_disk0]
type = "file"
path = "/dev/zvol/rdsk/rpool/propolis-dev/alpine-disk0"

# [dev.block0]
# driver = "pci-virtio-block"
# block_dev = "alpine_iso"
# pci-path = "0.4.0"

[dev.block01]
driver = "pci-nvme"
block_dev = "alpine_disk0"
pci-path = "0.4.1"

this worked with none of sections commented out, but after installing the OS to alpine-disk0 and commenting out that device, the VM no longer booted. what happens here is EDK2 enumerates the PCI bus, sees there's nothing at function 0, and then gives up on there being anything at later functions. from EDK2:

  for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {

    for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {

      //
      // Check to see whether PCI device is present
      //
      Status = PciDevicePresent (
                 Bridge->PciRootBridgeIo,
                 &Pci,
                 (UINT8) StartBusNumber,
                 (UINT8) Device,
                 (UINT8) Func
                 );

      if (EFI_ERROR (Status) && Func == 0) {
        //
        // go to next device if there is no Function 0
        //
        break;
      }

the least we could do is error about the boot order choices if the named item is not function zero while there is no function zero for that device. I don't think there's anything wrong with such a PCI configuration, but booting it with EDK2 means it probably won't yield what one expects..

Start in the propolis-standalone configuration handling for PCI paths and boot_order, then compare its behavior with the linked EDK2 PCI enumeration logic. Done means configurations with a non-zero PCI function and no function zero produce a clear warning or error explaining the boot-order risk.