Allow configuring storageClassMapping after cluster creation

In Kubevirt Hosted Clusters, the user can setup a storage class mapping between the host and guest clusters.

However that is only defined at cluster creation time and cannot be changed later, its immutable in the spec.

Once storageClassMapping is set, it cannot be changed, even if:

* The storage class becomes deprecated, renamed, or misconfigured — administrators are unable to update the mapping to a valid or recommended storage class.

* The underlying infrastructure changes — for example, transitioning from one storage backend (e.g., Ceph) to another (e.g., Portworx) cannot be reflected without recreating the HostedCluster.

* Recovery scenarios arise — a failing or non-functional storage class cannot be remapped to another without full cluster teardown and rebuild.

* GitOps management is hindered — if cluster specs are stored in Git and updated centrally, changes to storageClassMapping can't be applied to existing clusters, violating declarative and automated management practices.

Business Impact:  

* Breaks recovery workflows: No way to fix a broken mapping without full cluster recreation.

* Inflexibility in lifecycle management: Forces manual and disruptive re-creation of clusters when underlying infra changes.

* Inconsistent with expectations from OpenShift/Kubernetes where storage class defaults and mappings are mutable or at least patchable.

* Automation and GitOps breakage: Immutable config blocks fleet-wide updates to storage configuration.

Kubevirt Provider