vfio-pci: report from realize with the -device location, as QEMU does

[tamnd]

Part of #9.

QEMU realizes a -device with the option's location current, so a warning or error that vfio-pci prints during realize starts with "-device vfio-pci,...: ". ruvm printed the dma-buf warning from #337 without it. realize_x86() now pushes the plug's location for the length of realize, like qdev_device_add() does, so the dma-buf warnings and "Failed to mmap NAME BAR n. Performance may be slow" carry the same prefix as in QEMU. Errors that realize returns were already printed with the location and do not change.

Checked:

• On 220ceef, this branch with main (debd8d2) merged in, on server2: clippy with -D warnings and --all-targets for ruvm-mem, ruvm-hw-iommu, ruvm-sys, ruvm-hw-pci, ruvm-hw-vfio, ruvm-machine-x86, ruvm-machine-arm and ruvm-system, the same clippy for x86_64-pc-windows-gnu and aarch64-apple-darwin, the tests of ruvm-mem, ruvm-hw-iommu, ruvm-sys, ruvm-hw-pci and ruvm-hw-vfio and of the ruvm-machine-x86, ruvm-machine-arm and ruvm-system libs, and xtask unsafe-audit, provenance, layers and style. All passed, with 113 tests in the ruvm-system lib, 43 in ruvm-machine-x86 and 35 in ruvm-machine-arm. ruvm-machine-x86 has 3 fewer than before because machine-arm: migrate the PCI host of virt #338 moved its PCI vmstate tests to ruvm-hw-pci.
• On the release build of 19fd2c7, the change before the merge, an L1 run with the same setup as vfio-pci: mmap the BARs into the guest #337: QEMU 11.1 as L1 with an e1000e at 00:04.0 bound to vfio-pci, and L2 run as QEMU 11.1 and as ruvm with -device vfio-pci,host=0000:00:04.0,addr=2 under -S and qtest. Both print the same line, byte for byte:

qemu-system-x86_64: -device vfio-pci,host=0000:00:04.0,addr=2: warning: VFIO dma-buf not supported in kernel, using mmap fallback, P2P DMA will not work

Both also got all 778 of 778 answers with the same 71 distinct ones, and the same three mmaps of the device fd.