FR: Explore making it possible to deploy the Kubernetes operator API server proxy outside cluster

### What are you trying to do?

The [Kubernetes operator API server proxy](https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy) allows users accessing the Kubernetes API server over tailnet and, [in auth mode](https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy#configuring-authentication-and-authorization), gives a way to map tailnet identities to kube identities.
The proxy runs in the cluster itself, in process with the operator. Users who want to ensure that in disaster scenarios there is an alternative way how to access the API server that does not rely on an in-cluster component, would need to ensure another, additional mechanism.

Perhaps we could make it possible to deploy the API server proxy outside cluster, for example for EKS clusters it could be an ECS container on the same network as the API server. Users could configure it themselves with a kubeconfig.
This would allow folks to benefit from the tailnet user auth and private access while also not having to maintain additional break-glass mechanism for a disaster scenario.

I am not entirely sure what could constitute a good enough deployment/update flow:
- It would be great if there was some flow possible, perhaps using some 3rd party tooling to create such external nodes in sync with cluster creation (or perhaps
- The operator itself could create these nodes- but that would involve cloud provider (i.e. ECS) specific logic and either not being able to reconcile the containers or having to figure out how to use some cloud provider alternative to kube events

cc @jakedgy - this comes from our earlier discussion

### How should we solve this?

We should gather more use cases and explore what a good solution could look like

### What is the impact of not solving this?

Users in sensitive environments need to ensure an alternative out-of-cluster access mechanism for disaster scenarios