Allow liveness probes via queue-proxy when listening on localhost

## Describe the feature

Currently, all liveness probes are sent to the service container, which is expected to be listening on `0.0.0.0` on the container port. There is no reason that the service container needs to listen on all interfaces if all traffic is to be proxied via `queue-proxy` anyway. It would be good to support services that listen on `localhost` and to which `queue-proxy` will proxy the requests.

Today, the following config will send all liveness probes to the container, and readiness probes seem to be ignore or handled by the queue proxy (not sure, might be a separate issue).

```yaml
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /healthz
readinessProbe:
httpGet:
path: /readyz
```

```
Containers:
my-app:
Liveness: http-get http://:80/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
queue-proxy:
Readiness: http-get http://:8012/ delay=0s timeout=1s period=1s #success=1 #failure=3
```

It would be nice if we didn't have to expose the service on the pod network for this to work by allowing the `queue-proxy` to handle both liveness and readiness.

e.g.
```
Containers:
my-app:
Liveness: http-get http://:8012/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
queue-proxy:
Readiness: http-get http://:8012/ delay=0s timeout=1s period=1s #success=1 #failure=3
```

Start by locating queue-proxy's handling of liveness and readiness probes and compare it with the current service-container routing described here. Done means both probes can be handled through queue-proxy while the service container listens only on localhost; clarify the readiness behavior before implementation.

Written by the indexing model from the issue text.