Add maxRetry to RemediationStrategy in Machinedeployment

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

Currently, Cluster API's KubeadmControlPlane (KCP) supports a `remediationStrategy.maxretry` field to control the number of times remediation is attempted before giving up. However, MachineDeployment lacks a similar capability.

### Detailed Description

**Proposal:**
Introduce a maxRetry field under MachineDeployment.spec.strategy.remediation that integrates with MachineHealthCheck. This field would define the maximum number of remediation attempts allowed for unhealthy machines associated with a MachineDeployment.

**Use Case:**
In environments where aggressive or infinite remediation can lead to cascading failures or unnecessary resource churn, a retry limit helps provide guardrails for self-healing behaviour. Once maxRetry is reached, remediation would stop, and external signals (e.g., human intervention or alerting) can be relied upon.

**Benefits:**

- Parity with KubeadmControlPlane's remediationStrategy.maxRetry.
- Safer self-healing with better operational control.
- Prevents runaway remediation loops in edge scenarios.

```
spec:
strategy:
remediation:
maxRetry:
```

### Anything else you would like to add?

_No response_

### 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 comparing KubeadmControlPlane's remediationStrategy.maxRetry with MachineDeployment.spec.strategy.remediation and trace how MachineHealthCheck handles unhealthy MachineDeployment machines. Confirm the API shape, retry-limit behavior, validation, and compatibility expectations; the work is done when the field is integrated and its remediation behavior is covered by the project's tests.

Written by the indexing model from the issue text.