Configurable machine replacement

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

As a operator i would like to be able to configure a time after machines are getting replaced automatically for testing and security reasons.

### Detailed Description

# Problem Statement:
Regularly replacing machines help in testing application behavior during rolling updates and ensures machines are refreshed periodically, especially important after security incidents.

# Proposed Solution:
Implement `rolloutBefore.machineExpiry{Minutes,Hours,Days}` parameter within the Cluster API (like `rolloutBefore.certificatesExpiryDays` implemented for KCP), allowing users to specify the maximum time a machine should exist before being automatically replaced.

# Benefits:
- Testing Rolling Updates: Simplifies the process of regularly testing how applications behave during rolling updates.
- Security and Compliance: Ensures machines are periodically replaced, reducing the risk of lingering vulnerabilities and ensuring machines are clean post-security incidents.
- Operational Efficiency: Automates a routine maintenance task, reducing manual workload and the potential for human error.

# Impact:
- This feature would be highly valuable for IT operations teams managing Kubernetes clusters, particularly those with strict compliance and security requirements.
- It enhances cluster maintenance workflows, contributing to overall system reliability and security.

### Anything else you would like to add?

Current workarounds:
- setting `spec.rolloutAfter` periodically via CronJob for MachineDeployment
- running `clusterctl alpha rollout restart machinedeployment/my-md-0` periodically

### 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.