Allow version skew of MachineDeployments when using clusterclass

### What would you like to be added (User Story)?

As an operator I would like to control the version of machinedeployments independent of each other and the control plane while using clusterclass.

### Detailed Description

Currently, the version of the control plane and all machinedeployments are controlled through one value `cluster.spec.topology.version`. Updates here trigger updates to the control plane and all worker groups.

I'd like to expose an optional value on each MachineDeploymentTopology and MachinePoolTopology to control the version to give operators more control over the upgrade process.

Our use case is we want to orchestrate patching of worker groups independent of the control plane and independent of other worker groups.

### Anything else you would like to add?

My team would be happy to work on this feature. I'm talking about patch version skew specifically here. We'd probably want controls that only patch version is being skewed.

### Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

Start by reviewing the ClusterClass topology version handling and the MachineDeploymentTopology and MachinePoolTopology API definitions mentioned in the issue. Trace how cluster.spec.topology.version updates the control plane and worker groups. Done means an optional per-topology version can coordinate independent worker-group upgrades while limiting the supported skew to patch versions.

Written by the indexing model from the issue text.