feature request: support for kubernetes api HTTP proxy so that tools like helm work with cloudflared

I'm a new user of `cloudflared` and although setup has been quite bumpy, I have come to understand what it achieves and can do. And I love it!

The new support of kubectl is just what I needed to make the final jump but it still falls short of providing full support for kubernetes tooling.

In particular, I'm thinking of `helm` and helm-related tools. The setup [recommended in the docs](https://developers.cloudflare.com/access/other-protocols/kubectl/) works by providing a tunnel via `HTTPS_PROXY` env variable. That's fine for `kubectl` since all commands consume the kubernetes api and there is no need to access the public internet.

However, as I understand it, the `kubectl` ecosystem expects `HTTPS_PROXY` to be just that (i.e.: a http proxy with access to the internet and capable of doing routing). It seems that the command

`cloudflared access tcp --hostname cluster.site.com --url 127.0.0.1:1234`

is not providing that, but a tcp/socks5 proxy that routes all traffic to the same endpoint.

By not following the assumption that `HTTPS_PROXY` is meant to be used for the http protocol, cloudflared makes helm to fail. I've tried following the same logic for helm,and so I may have:

```
alias helm="env HTTPS_PROXY=socks5://127.0.0.1:6444 helm"
```

This makes commands like `helm list` to fully work since there is only one routing to the api server. However commands like `helm repo update` or `helm repo add` fail because the `HTTPS_PROXY` is not routing the request to the public internet. Helm fails because for every https request it makes, it gets the same tls certificate back: that of the kubernetes api server.

I've managed to make helm work with a setup which is far more complex than I would like to.

With something like this:

```
alias kubectl="env HTTPS_PROXY=socks5://127.0.0.1:1234 kubectl"
alias helm="helm --kube-apiserver 127.0.0.1:6443"
kubectl proxy --port=6443
```

I get to achieve the minimum required:

- kubectl connects via argo tunnel
- kubectl forwards the api server to the local network
- helm does not use HTTPS_PROXY but instead knows that when making requests to the api, it should use localhost instead of the server address in kubeconfig

In an ideal world, I would guess that something like:

```
cloudflared access http --hostname cluster.site.com --url 127.0.0.1:1234
```

would solve the problem in terms of providing that extra layer of an http proxy, instead of tcp/socks5.

I don't know how complex this would be to implement, but it seems to me like it would just be the missing cherry on top