Config overrides: use apiVersion instead of group for easier UX

[frobware]

This is an experiment building on @andreaskaris's work in #475.

After reviewing the override functionality, I wanted to explore a couple of changes that I think make the feature easier to use and more robust.

What changed

1. Replace group with apiVersion in the override spec

The original implementation required users to specify:

- kind: DaemonSet
  group: apps
  namespace: bpfman
  name: bpfman-daemon
  unmanaged: true

This means users need to remember API group names (apps, storage.k8s.io, empty string for core resources, etc.) and mentally split apiVersion into group/version.

The new approach uses apiVersion directly:

- apiVersion: apps/v1
  kind: DaemonSet
  namespace: bpfman
  name: bpfman-daemon
  unmanaged: true

This is the same format users see in kubectl get -o yaml output, so they can copy/paste directly. No need to remember that ConfigMaps have an empty group or that DaemonSets live in apps.

2. Use scheme-based GVK resolution

The original implementation matched overrides using resource.GetObjectKind().GroupVersionKind(). This is fragile because many objects constructed in code don't have their TypeMeta populated - it's only reliably set when objects are decoded from the API server.

The PR had already worked around this by manually adding TypeMeta to the ConfigMap:

cm := &corev1.ConfigMap{
    TypeMeta: metav1.TypeMeta{
        Kind:       "ConfigMap",
        APIVersion: "v1",
    },
    // ...
}

The new approach uses the controller's scheme to resolve GVK:

gvks, _, err := scheme.ObjectKinds(resource)

This works reliably for all objects regardless of how they were constructed, so we can remove the manual TypeMeta workaround.

Testing

I've tested this on a kind cluster:

1. Added an override for the DaemonSet
2. Verified the operator logs show "Skipping unmanaged resource (override in place)"
3. Modified the DaemonSet spec - changes persisted (operator skipped it)
4. Deleted the DaemonSet while unmanaged - it stayed deleted
5. Removed the override - operator recreated the DaemonSet

The escape hatch semantics work as expected: complete hands-off while unmanaged, operator resumes control when the override is removed.

Summary

These changes are subjective improvements for UX and robustness. The core override functionality from #475 is unchanged - this just makes it easier to configure and removes a potential source of silent matching failures.

Happy to discuss if there are concerns or alternative approaches.