bhyve: register a BAR again once the range it wanted is free

[wanpengqian_gmail.com]

Summary

A guest that reassigns the BARs of several devices without turning
decoding off, as Linux does on arm64, routinely puts a BAR where another
device's BAR still is; that one moves away a moment later.

register_mem() reports success without registering anything when the
new range starts inside a registered one, and returns an error when it
overlaps one otherwise. Either way modify_bar_registration() never
tries again, and in the first case it even believes the BAR is
registered. The BAR then stays without a handler for good: its accesses
fall through to the PCI fallback handler, reads return all ones, and
for instance a virtio 1.0 driver waits forever for device_status to
read 0 after a reset.

The silent success dates from 028d9311cdfb (April 2013), which let the
guest reprogram BARs and made register_mem() look the base up first and
add the range only if nothing was found there. 6f051f0e5 (D60748,
October 2026) made a failed registration non-fatal and records it in
pcibar.registered; this change builds on that and registers such a BAR
once its range is free.

Make register_mem() fail with EEXIST in the first case too, and try the
unregistered BARs of all devices again whenever a BAR has moved or a
device's decoding has changed.

Fixes: 028d9311cdfb ("Improve PCI BAR emulation")
Signed-off-by: Wanpeng Qian <[e-mail]>
Sponsored by: keelos.dev

Test Plan

Built usr.sbin/bhyve on main 7cb4d4dfd with and without the change, plain
and WITH_BHYVE_SNAPSHOT, -Werror: 0 warnings. This is a follow-up to
D60748 (6f051f0e5), which made a failed BAR registration non-fatal: after
that change the BAR stays unregistered even once its range is free.

Reproducer in a FreeBSD main guest with two extra e1000 devices (slots 8
and 9), their drivers detached with devctl so that only pciconf touches
them, memory decoding left on. BAR0 of slot 8 is at 0xc0020000, BAR0 of
slot 9 at 0xc0040000; the first 16 bytes of each read
00000040 00000000 00000083 00000000 (CTRL, -, STATUS, -) through /dev/mem.

pciconf -w pci0:0:9:0 0x10 0xc0020000   (9 onto 8, 8 still there)
pciconf -w pci0:0:8:0 0x10 0xd0000000   (8 moves away)
read 0xc0020000 (now only slot 9's BAR)

without the change: ffffffff ffffffff ffffffff ffffffff (no handler,
                    slot 9's BAR0 is never registered again)
with the change:    00000040 00000000 00000083 00000000

0xd0000000 (slot 8) reads correctly in both. Linux on arm64 does exactly
this when it reassigns BARs with decoding on; with a virtio 1.0 device the
driver then waits forever for device_status to read 0 after a reset.

Also booted FreeBSD main and Debian 13 (UEFI) guests with ahci, e1000,
virtio-blk/net/rnd: no change in behaviour.