Expose all vm-operator volume parameters in VSphereMachine spec.volumes

[randomvariable]

User Story

As a cluster operator, I want to configure all vm-operator VirtualMachineVolume parameters through CAPV's VSphereMachine.spec.volumes, so that I can control disk attachment behavior (controller type/bus/unit, disk mode, sharing mode, application type, removability, read-only) for additional data disks and let my bootstrapper know of them from advance.

Detailed Description

VSphereMachineVolume (api/supervisor v1beta1/v1beta2) currently exposes only name, capacity, and storageClass. When CAPV builds the vm-operator VirtualMachine spec (pkg/services/vmoperator/vmopmachine.go), it sets only Name + PersistentVolumeClaim.ClaimName (+ hardcoded ReadOnly: false) on each volume.

vm-operator (served as v1alpha5/v1alpha6; CAPV's conversion hub↔spokes already round-trips all fields) supports:

• applicationType (OracleRAC, MicrosoftWSFC)
• controllerType (IDE, NVME, SCSI, SATA)
• controllerBusNumber
• diskMode (Persistent, NonPersistent, IndependentPersistent, IndependentNonPersistent)
• sharingMode (None, MultiWriter)
• unitNumber
• removable
• readOnly

These should be exposed on VSphereMachineVolume and passed through to the vm-operator VM spec.

Additionally, addVolume currently dedups volumes by ClaimName and returns early, so changes to volume parameters in the spec are silently ignored on subsequent reconciles — this should become upsert semantics.

Anything else you would like to add:

/kind feature
/area api

[randomvariable]

/area supervisor

[randomvariable]

/assign

[randomvariable]

/lifecycle active

[sbueringer]

/triage accepted

[sbueringer]

Please add a v1alpha5+ feature gate for this (it's the easiest and most consistent way to gate this for specific vm-op apiVersions)

Let's also validate via webhooks that these fields are only set if the feature gate is on