Replace exponential backoff retry with a simple 2s polling loop,
consistent with other drivers (vfkit, krunkit, qemu).

Before (exponential backoff, actual timestamps from logs):

   0.000s  attempt 1
   0.219s  attempt 2
   0.492s  attempt 3
   0.900s  attempt 4
   1.284s  attempt 5
   2.016s  attempt 6
   2.952s  attempt 7
   4.025s  attempt 8
   5.103s  attempt 9
   6.477s  attempt 10
   8.066s  attempt 11
  10.230s  attempt 12
  12.566s  attempt 13
  15.990s  attempt 14
          (retry.go: will retry after 5.3s)
  21.285s  attempt 15  <-- found IP

After (fixed 2s interval, actual timestamps from logs):

   0.000s  attempt 1
   2.005s  attempt 2
   4.010s  attempt 3
   6.015s  attempt 4
   8.020s  attempt 5
  10.025s  attempt 6
  12.031s  attempt 7
  14.037s  attempt 8
  16.042s  attempt 9
  18.046s  attempt 10  <-- found IP

The first 7 attempts in the old schedule fire within 2.9 seconds at
sub-second intervals. DHCP negotiation cannot complete this fast, so
every one of these attempts is guaranteed to fail — they only add load
on libvirt.

The last attempts 10-15 waited more than 2 second, increasing the time
to detect the IP, slowing start time by 3.2 seconds. Exponential backoff
is not the right tool for this job.

- Pass the domain object to avoid LookupDomainByName on every iteration
- Use d.PrivateMAC directly instead of parsing domain XML for the MAC
- Log start with timeout and finish with elapsed time
- Log attempt count for easier debugging
- Extract lookupIP and reserveIP to clarify the wait loop flow

The KVM driver's GetIP() re-queries libvirt for the IP address on every
call instead of returning the stored d.IPAddress. This causes a bug
under parallel stress:

Call chain:
  1. waitForStaticIP() finds IP, sets d.IPAddress = "192.168.x.x"
  2. Start() returns successfully
  3. saveHost() calls api.Save(h) — persists driver JSON (with IP set)
  4. saveHost() calls h.Driver.GetIP() to store in node config (n.IP)
  5. GetIP() ignores d.IPAddress, opens 2 new libvirt connections,
     calls ipFromXML() which queries dhcpLease() for the MAC
  6. Under stress, dhcpLease() returns nil (lease not yet visible in
     the network's DHCP database) — returns ("", nil)
  7. saveHost() stores n.IP = ""
  8. setupKubeconfig() calls ControlPlaneEndpoint() with cp.IP = ""
  9. net.LookupIP("") fails → "failed to lookup ip for \"\""

Fix by returning the stored d.IPAddress when available (fast path),
falling back to querying libvirt only when the IP is not stored and
the domain is running. This is consistent with vfkit and krunkit which
also return the stored IP directly.

The fallback queries the domain's live interface addresses
(ListAllInterfaceAddresses) rather than the network's DHCP lease
database (GetDHCPLeases). This is more reliable because:
- The domain's interfaces reflect the actual assigned IP
- The lease database may be stale when addStaticIP races with
  concurrent network updates from other VMs
- No need to look up the MAC from domain XML (d.PrivateMAC is known)

Currently acquireMachinesLock uses a single lock per driver, serializing
all "minikube start" commands for profiles using the same driver. This
was needed for VirtualBox (VBoxManage cannot handle concurrent calls) but
is unnecessary for drivers where each profile creates an independent VM
or container with no shared global state.

In drenv (RamenDR test framework) we create 3 minikube clusters in
parallel using kvm2. Due to the shared lock, cluster creation is
serialized for ~25 seconds per cluster:

  [hub] Cluster started in 41.09 seconds
  [dr2] Cluster started in 64.46 seconds
  [dr1] Cluster started in 89.48 seconds

All three clusters are requested at the same time, but the lock forces
them to wait. The ~48 second spread between the first and last cluster
is pure lock serialization overhead. The random lock acquisition order
causes up to 50 seconds of runtime variance between runs (p95: 6m50s
when both large clusters start first vs 7m40s when they start last).

Add a Parallel property to the driver registry. Drivers that set
Parallel to true use a per-profile lock, allowing concurrent creation of
multiple profiles. Drivers that do not set it (default false) keep the
current serialized behavior.

Enable parallel start for kvm2, qemu2, vfkit, krunkit, docker, and
podman. These drivers create fully independent VMs or containers and
have no shared state that requires serialization. Other drivers
(virtualbox, vmware, hyperv, hyperkit) are left serialized until someone
tests them and confirms they are safe.