NE: vif.binding=lswitch hook for OVS-backed extensions

[msinhore]

Summary

Adds an opt-in hook so a NetworkOrchestrator extension backed by an OVS+OVN
datapath (or any other host-side stack that consumes the libvirt
<virtualport interfaceid=…> element) can declare vif.binding=lswitch
in its extension_details and have the framework wire the binding for
free.

When the hint is set, NetworkExtensionElement.prepare() flips the
NicProfile to BroadcastDomainType.Lswitch and persists
broadcast_uri / isolation_uri as ovn://cs-net-<networkId> on the
nics row, and implement() does the same on the networks row.
That is enough for the existing OvsVifDriver on the KVM agent to emit
<virtualport type='openvswitch'><parameters interfaceid='<nic.uuid>'/>
without any agent patch — libvirt sets external_ids:iface-id=<nic.uuid>
atomically with tap creation, and ovn-controller binds the LSP whose
name matches.

The framework also propagates nic.getUuid() to per-NIC script
commands as --nic-uuid, so the extension can use the canonical UUID
as the LSP name and stay in sync with what libvirt writes on the host.

Without the hint, behaviour is byte-identical to the current PR.

Commits

1. NE: VIF binding hooks for OVS-backed extensions — adds the two
   public constants on ExtensionHelper (VIF_BINDING_DETAIL_KEY,
   VIF_BINDING_LSWITCH), the --nic-uuid propagation, and the
   broadcast-type override in prepare(). Also extends the framework
   README with the binding contract:
   nic.uuid == libvirt iface-id == OVS external_ids:iface-id == OVN LSP name == OVN SB Port_Binding.logical_port.
2. NE: persist OVN broadcast/isolation URI on NIC — sets
   nic.broadcastUri / nic.isolationUri to ovn://cs-net-<id> and
   persists via nicDao.update() so listNics and the UI advertise
   the OVN URI rather than the VLAN URI the GuestNetworkGuru allocates
   at design-time.
3. NE: persist OVN broadcast type and URI on Network — does the
   same on the Network row in implement() so listNetworks
   matches.

Why these belong in the framework

The broadcast type / URI are read by OvsVifDriver before the
extension script runs, and they live in DAOs the script cannot touch.
The hook has to be in the Java prepare() / implement() flow.

Risk surface

Three files, +219/−2 lines, all under framework/extensions/.../network/
plus 24 lines of constants in api/.../extension/ExtensionHelper.java.
No SQL migration, no new Cmd, no new response object. Existing
extensions (HyperV, MaaS, Proxmox) are untouched because they don't
declare vif.binding=lswitch.

Lab validation

End-to-end on an isolated OVN network and a VPC tier:

• VM NIC bound on libvirt → OVS iface-id matches nic.uuid
  → OVN SB Port_Binding.logical_port matches → ovn-controller
  installs flows.
• listNetworks / listNics / network-detail UI show
  ovn://cs-net-<id> instead of vlan://<id>.
• DHCP, DNS, SourceNat, StaticNat, PortForward, Firewall (ingress and
  egress), Public LB and Internal LB all functional.

Test plan

• Boot a VM on an extension-backed network whose extension declares
  vif.binding=lswitch; confirm ovs-vsctl list interface shows
  iface-id=<nic.uuid> and that ovn-sbctl find port_binding logical_port=<nic.uuid> returns one row with the chassis bound.
• Boot a VM on an extension that does NOT declare the detail;
  confirm broadcast type stays Vlan and --nic-uuid is not
  propagated to the script.
• Run listNetworks and listNics and verify the URI fields read
  ovn://cs-net-<id> after the network is implemented.

[weizhouapache]

Merged, thanks @msinhore !!!