feat: CARP addresses as virtual IPs, with their holder in the reading (4.10.0)

A firewall pair's CARP addresses are a third virtual IP mechanism. Unlike
vip-manager and keepalived, a CARP reading says who holds the address: a
firewall's interface list need not show it, but CARP's state names the MASTER.

- VirtualIpsDict gains carp (NotRequired), VirtualIpDict gains holds
  (NotRequired; None leaves the holder to the interfaces).
- carp_virtual_ip() shapes one address bound to a VHID: MASTER holds, BACKUP
  stands by, INIT and DISABLED neither run nor hold, an unknown state says
  nothing. The same for OPNsense and pfSense; a driver supplies the fields.

netOrk #1121.

README.md

@@ -128,6 +128,14 @@ A mechanism it could not read completely is `None` ("did not look"), a host with
 `[]`. The command is about 4 kB, so a driver sends it on an exec channel
 (`_run_virtual_ips_command(command, privileged=)`), not typed into a shell.
 
+A firewall's CARP addresses are a third mechanism, `carp`, which a firewall driver reads
+from its own API and reports under the reading's `carp` key (`vip_manager` and
+`keepalived` then None). `carp_virtual_ip(...)` turns one address bound to a VHID into the
+entry -- the same for OPNsense and pfSense. Unlike the other two, a CARP entry says who
+holds the address (`holds`): every member carries the address in its configuration, and a
+firewall's interface list need not show it, but CARP's state names the MASTER. A state it
+does not know leaves `holds` None, and the caller falls back on the interfaces.
+
 `SystemIdentityMixin` (`get_system_identity`) reads a host's SMBIOS identity -- system UUID,
 product serial and board serial from `/sys/class/dmi/id` -- which is what ties a server to
 its BMC (`ManagementControllerDriver.get_hardware_inventory` reports the same values from