CAPI controllers should add finalizers into templates if the templates are necessary for updates.

**What steps did you take and what happened:**

Changes in KubeadmConfigTemplate don't trigger any rollout https://github.com/kubernetes-sigs/cluster-api/issues/4910.

To be able to update the config, you need to create a new KubeadmConfigTemplate and update the reference in MachineDeployment. If you delete the existing KubeadmConfigTemplate, capi controller cannot complete the update.

**What did you expect to happen:**

capi-controller should add finalizers into templates if they are necessary to roll out some changes.

**Anything else you would like to add:**

Clients are responsible for declaring the desired state and I think storing old templates is not one of the clients' responsibilities. If controllers need to have a CR for any functionality, they should put their finalizers into resources to prevent any problematic deletion.

For the clients designed in a declarative way (e.g. gitops + flux, helm), it is tough to complete an update in one move. In the current design, we have to do some hacks like adding our own finalizers into templates and cleaning with our custom operator or doing upgrades in two moves. Both of them are so problematic.

**Environment:**

- Cluster-api version: cluster-api-controller:v1.1.3
- Kubernetes version: (use `kubectl version`): v1.22.9
- OS (e.g. from `/etc/os-release`):

/kind bug

Start by tracing the capi-controller handling of KubeadmConfigTemplate and how MachineDeployment references it. Reproduce the update and deletion sequence described in the issue, then inspect existing controller tests for template lifecycle behavior. Done means the update can complete without clients retaining templates themselves, while deletion remains safe during rollout.

Written by the indexing model from the issue text.