Enhancement of Authentication and Authorization Filters to Allow Custom Configurations and Stability Improvements

## Enhancement Proposal: Authentication and Authorization Filters

**Context**: Following the implementation introduced in [PR #2407](https://github.com/kubernetes-sigs/controller-runtime/pull/2407), several issues regarding configurability and robustness were identified.

### Issues Identified

- **Configurability**: Current settings such as cache TTL, timeouts, and anonymous access are hardcoded and cannot be adjusted.

- **Certificate Authentication**: The implementation disrupts normal certificate authentication processes. See that it shows like to have the same security issue identified by auth-sig which is a breaking change in [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy) over `The ability to run kube-rbac-proxy without TLS certificates will be removed.` shows be applied here. Users should provide their certificates and/or use solutions as cert-manager to manage them accordingly. It seems that is not a good practice to manage them. [More info](https://github.com/kubernetes-sigs/kubebuilder/issues/3524#issuecomment-1703190748).

- **Authorization Flexibility**: Lack of support for `alwaysAllow` configurations for critical paths like `/healthz` and `alwaysAllowGroups` like `system:masters`.

- **Network Resilience**: Heavy dependency on stable connectivity to kube-apiserver can lead to metrics outages under network instability.

### Proposed Changes

Enhance the filters by introducing configurations for previously hardcoded settings, and by allowing the injection of custom authorizers, similar to the approach in [kube-rbac-proxy PR #43](https://github.com/openshift/kube-rbac-proxy/pull/43) and the see the PR: https://github.com/brancz/kube-rbac-proxy/pull/125/files

### Impact

These changes would enhance the flexibility and reliability of the authentication and authorization processes in controller-runtime, aligning with the needs of robust Kubernetes deployments.

c/c @deads2k @sbueringer

Start by reviewing the authentication and authorization filter implementation introduced in PR #2407, then compare the configuration and custom-authorizer approaches referenced from kube-rbac-proxy PRs #43 and #125. Done would require an agreed design covering configurable cache TTLs, timeouts, anonymous access, certificate authentication, always-allow rules, custom authorizers, and resilience during kube-apiserver network instability.

Written by the indexing model from the issue text.