VMInstance: model the new disks[].hotpluggable field (upstream cozystack#3978) #35

Upstream cozystack/cozystack#3978 adds an optional hotpluggable flag to each entry of the vm-instance disks list. When set, the chart marks the generated volume hotpluggable: true, which is what KubeVirt requires to attach or detach a volume while the VM is running; without it the volume only reaches the guest after a restart.

The provider models disks[] by hand as {name, bus} — internal/provider/vminstance_schema.go, in the resource schema and again in the data source schema — plus the matching model and its expand/flatten pair. So the new field is not settable, and not readable either.

Shape: optional bool, no default. Two constraints worth carrying into the description rather than the validators, since both are enforced elsewhere and would drift:

• it needs the DeclarativeHotplugVolumes feature gate on the cluster, which the provider cannot see;
• the chart refuses hotpluggable unless bus is scsi or virtio, because KubeVirt's own admitter does (ValidateHotplugDiskConfiguration). A provider-side stringvalidator on bus would be wrong: any bus stays valid for a disk that is not hotpluggable.

Omitting the field keeps today's behaviour, so this is backward compatible.

Filed rather than sent as a PR because the api/apps/v1alpha1 pin has to move past the upstream merge first — shipping the attribute before that would give users a Terraform field that silently does nothing, which is exactly the failure mode the upstream change is meant to remove.