CustomResourceState move from GroupVersionKind to GroupVersionResource

[mrueg]

What would you like to be added:
Currently the configuration requires to set a Group, a Version and a Kind, CRS should either move to or additionally accept a Group Version Resource option.
Why is this needed:
We run into issues with pluralizing the kind and if we use resources, we also can generate RBAC roles from the existing CRS config without figuring out what resource we need to attach it to.
Describe the solution you'd like

Ideally we drop the Kind and make it GroupVersionResource to limit the scope effectively. This is breaking existing configs, but it's an experimental feature, so we can still iterate on it.

Additional context

[logicalhan]

great!

/triage accepted
/assign @rexagod

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[rexagod]

It makes sense to acknowledge the resolution on kubernetes-sigs/kubebuilder#3402 and not make them dependent on the "broken" pluralization logic upstream. Both of these places have procedures, albeit differing in nature, which if modified will have far-reaching repercussions.

Practically, any repository should follow the conventions set by its upstream to persist similar expectations across the ecosystem, however, if that should still be the case if the "conventions" (pluralization logic in k/k) are less than ideal is a grey area in itself.

IMHO we probably should stick to flect, since apimachinery acknowledges the procedure is broken, and implicitly, as I'm assuming, discourages depending on it.