helm: fix dependent resource watches that miss changes

[AbhishekPathania]

Description of the change:

With watchDependentResources: true, editing or deleting a resource from the chart should reconcile the owning custom resource. For many resources it does not. The event reaches the controller, but no handler enqueues the owner, so the change stays until the next periodic reconcile.

watchDependentResources picks a handler per dependent: EnqueueRequestForOwner, or EnqueueRequestForAnnotation for resources that ownerRefInjectingClient.Build annotated instead of owning. That choice has to match what Build did to the resource, and it did not in four cases. Each commit fixes one of them and adds a test for it.

1. A template that omits metadata.namespace has an empty namespace in the stored manifest, so it was compared against "" and got the annotation handler. Helm installs it into the release namespace, where Build gives it an owner reference. The release namespace is now used when the resource has none.
2. Watches were keyed by GVK, so the first resource of a kind chose the handler for all of them. A kind rendered both in the release namespace and in another namespace got one handler, and since releaseutil.SplitManifests returns a map, which one could change on every restart. Watches are now keyed by GVK and handler type.
3. Resources with helm.sh/resource-policy: keep are annotated instead of owned since fix: (helm) - do not add owner references to resources that contain the Helm keep resource-policy annotation #4389, but the watch decision did not check for keep. It now uses the same helper as Build. helm-operator-plugins made the same change in objects with resource policy "keep" should use the annotation-based watch helm-operator-plugins#83.
4. EnqueueRequestForAnnotation only enqueues when operator-sdk/primary-resource-type equals its Type. SetOwnerAnnotations writes the owner's GroupKind there, but Type was the dependent's GroupKind, so the handler never enqueued anything. This covers every cluster-scoped and cross-namespace dependent, which is the behavior reported in Helm Operator missing ownerReferences for ClusterRole and ClusterRoleBinding #2727. Type is now the owner's GroupKind, as in helm-operator-plugins.

The tests read the handler from controller-runtime's source.Kind through reflection, because source.Kind does not expose it.

Motivation for the change:

We run a Helm-based operator with a longer reconcile period and rely on dependent watches to undo manual changes to chart resources. On v1.42.1, changes to cluster-scoped resources, resources in other namespaces and keep resources were not undone until the next periodic reconcile, and neither were some kinds in the release namespace. With these commits they trigger a reconcile within about a second.

Checklist

If the pull request includes user-facing changes, extra documentation is required:

• Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
• Add or update relevant sections of the docs website in website/content/en/docs