This leverage the Kubernetes GC to delete kubevirt VMs, by using
ownerReferences, with the CI pod running the playbook as the owner.
This concretely means that the control plane in our CI cluster will
delete the kubevirt VMs associated with a particular ci job as soon as
that pod job is deleted, which usually happens when the job terminates,
(barring errors, which will be addressed in the cluster directly)

Upgrade to kubevirt.io/v1 for the VirtualMachine manifests, since the
alpha version is deprecated.

Kubevirt VMs deletion will be handled by the Kubernetes GC (see previous
commit), remove all the codes handling that.

Also, use the Ready condition of VirtualMachine instead of
custom checks

Not constraining the inventory to .ini allows us to use dynamic
inventory, which is needed for simplifying kubevirt jobs inventory.

Also reduces the scope of the ANSIBLE_INVENTORY variable.

This allows a single source of truth for the virtual machines in a
kubevirt ci-run.

`etcd_member_name` should be correctly handled in kubespray-defaults for
testing the recover cases.

VMI in Kubevirt are the abstraction below VirtualMachine.

- We don't really need the extra abstraction of VirtualMachine objects
- Fix the provisioning playbook not waiting correctly on the VMs until
  they have an IP address to use for the dynamic inventory