Implement correct upgrade procedure for provider manifest

[Danil-Grigorev]

What steps did you take and what happened:
Currently, if a user changes version of the provider manifest, old components are getting removed, and new ones for the version are installed. This process does not include CRD migration.

Additionally, if the provider spec hash changes, then this triggers same logic, forcing a full re-apply of infrastructure.

What did you expect to happen:

• CRD migration (prevent issues similar to this)
• Align with clusterctl on how to act when provider version changes.
  • Installed version matches expected version - install current modified manifests.
  • Version differs - execute clusterctl upgrade procedure.
  • Provider is getting deleted - remove deployed manifests from the cluster.

/kind bug

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Danil-Grigorev]

/assign