rpk: provide alternative to ClusterRoleBinding for `rpk debug bundle` in k8s environments

Who is this for and what problem do they have today?

Currently, rpk relies on having a ClusterRole to collect the information needed for the debug bundle, see:

https://docs.redpanda.com/current/manage/kubernetes/troubleshooting/k-diagnostics-bundle/#generate-a-diagnostics-bundle

This is done to:

1. Discover the admin API addresses of the cluster, currently, there is no way to do that. (See https://github.com/redpanda-data/redpanda/issues/8975).
2. Collect the Logs of every pod in the cluster, this saves time in large clusters since the user only has to create one bundle instead of n-bundles.
3. Collect k8s resources in the Redpanda namespace, for debugging.

Alternatives discussed:

This issue is to track the discussion, but the alternatives discussed are:

• Use kubeconfig to authenticate, the bundle would have to be fired off from the debugger's machine, read the kubeconfig, and authenticate. This will allow collection of the Logs and Resources, but it has its limitations regarding the Admin API calls.
• Use RoleBinding, so it stays in the namespace.

JIRA Link: CORE-2649

Start with the rpk debug bundle entry point and the linked Kubernetes diagnostics-bundle documentation to understand the current ClusterRole requirements. Compare the kubeconfig and namespace-scoped RoleBinding alternatives, including their stated limitations, and clarify which approach should preserve the required log, resource, and Admin API collection before implementation.