feat: Smooth ClusterProfile/Profile transitions

[gianlucam76]

Introduces a TransitionFrom field to ClusterProfile/Profile to allow a successor profile to declare its predecessor.

When migrating a cluster between profiles via a label swap, shared resources are taken over in place—eliminating the unnecessary teardown and re-deployment cycle.

Currently, moving a cluster from ClusterProfile1 to ClusterProfile2 via a label swap forces a full tear-down-then-build lifecycle. ClusterProfile1 undeploys all of its managed resources before ClusterProfile2 begins deploying. Even for resources shared or identically configured between both profiles.

Example: Changing a cluster's label from sbom: v1 (matching ClusterProfile1) to sbom: v2 (matching ClusterProfile2) triggers a complete undeployment of ClusterProfile1's resources before ClusterProfile2 deploys its workload.

• API Spec: add TransitionFrom field to profile spec.
• Defer predecessor teardown until the successor is ready: hold off on deleting the old profile's resources until the new profile is fully up and running. To avoid timing issues caused by parallel updates, code check the cluster's labels directly to identify the incoming profile rather than waiting for it to register in the system. If multiple new profiles are taking over, wait until all of them are ready before removing the old one.
• Let the successor win the resource-ownership conflict: a second, tier-independent path to "takeover allowed" when the resource's current owner is named in the claiming profile's TransitionFrom.
• Same for Helm: a mirrored bypass against chartmanager's tier check, since Helm ownership is a separate subsystem from raw-resource ownership.
• Pull mode: TransitionFrom staged onto ConfigurationGroup so sveltos-applier can grant the same takeover locally.

Fixes #1949