Allow passthrough devices to be hinted.

Allow the ppt driver to attach to devices that were hinted to be
passthrough devices by the PCI code creating them with a driver
name of "ppt".

Add a tunable that allows the IOMMU to be forced to be used.  With
SR-IOV passthrough devices the VFs may be created after vmm.ko is
loaded.  The current code will not initialize the IOMMU in that
case, meaning that the passthrough devices can't actually be used.
Implement interface to create SR-IOV Virtual Functions

Implement the interace to create SR-IOV Virtual Functions (VFs).
When a driver registers that they support SR-IOV by calling
pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov
for that device.  An ioctl can be invoked on that device to
create VFs and have the driver initialize them.

At this point, allocating memory I/O windows (BARs) is not
supported.
Emulate the Device ID and Vendor ID registers for VFs

The SR-IOV standard requires VFs to read all-ones when the VID
and DID registers are read.  The VMM (hypervisor) is required to
emulate them instead.  Make pci_read_config() do this emulation.

Change pci_user.c to use pci_read_config() to read config space
registers instead of going directly to the pcib so that the
emulated VID/DID registers work correctly on VFs.  This is
required both for pciconf and bhyte PCI passthrough.
Allocate PCI I/O memory spaces for VFs

When creating VFs, we must size each SR-IOV BAR on the PF and
allocate a configuous I/O memory window large enough for every VF.
However, the window only needs to be aligned to a boundary equal
to the size of the window for a single VF.

When a VF attempts to allocate an I/O memory resource, we must
intercept the request in the pci driver and pass it off to the
SR-IOV code, which will allocate the correct window from the
pre-allocated memory space for the PF.

Inform the pci driver about the size and address of the BARs on
the VF when the VF is created.  This is required by pciconf -b and
bhyve.
Add interface to destroy SR-IOV VFs
Add infrastructure for exporting config schema from PF drivers
Add function to validate the consistency of SR-IOV config

Add a function that validates that the user-provided SR-IOV
configuration is valid.  This includes basic checks that the
structure of the configuration is correct (e.g. all required
configuration nodes are present) as well as validating against
a configuration schema.

The schema validation consists of:
 - Ensuring that all required config parameters are present.
 - If the schema defines a default value for a parameter,
   adding the default value if the parameter is not set.
 - Ensuring that no parameters are specified in the config
   that are not defined in the schema.
 - Ensuring that have the correct type defined in the schema.
 - Ensuring that no configuration nodes are present for devices
 that do not exist.  For example, if 2 VFs are configured,
 then we validate that a node called VF-5 does not exist.
Pass SR-IOV configuration to kernel using an nvlist

Pass all SR-IOV configuration to the kernel using an nvlist.  The
main benefit that this offers is flexibility.  It allows a driver
to accept any number of parameters of any type supported by the
SR-IOV configuration infrastructure with having to make any
changes outside of the driver.

It also offers the user very fine-grained control over the
configuration of the VFs -- if they want, they can have different
configuration applied to every VF.
Add iovctl functions for validating config

Add an function to iovctl that validates the configuration against
a schema.  This function is able to assume that the parser has
done most of the validation already and it's only responsible for
applying default VF values specified in the config file, confirming
that all required parameters have been set and that no invalid VF
numbers have been specified.
Add functions for parsing the iovctl config file

Add two functions for parsing the iovctl config file.  The config
file is parsed using libucl[1], which accepts most YAML files and
a superset of JSON.  The first function is an ad-hoc parser that
searches the file for the PF.DEVICE configuration value.  We need
to know that value in order to fetch the schema from the kernel,
and we need the schema in order to be able to fully parse the file.

The second function parses the config file and validates it
against a schema.  This function will exit with an error message
if any validation error occurs.  If it succeeds, the configuration
is returned as an nvlist suitable for passing to the kernel.

[1] https://github.com/vstakhov/libucl
Add main() for iovctl and hook iovctl into build