Update status of GrpcWeb filter

https://www.envoyproxy.io/docs/envoy/v1.27.0/intro/arch_overview/other_protocols/grpc says:

> gRPC-Web is supported by a [filter](https://www.envoyproxy.io/docs/envoy/v1.27.0/configuration/http/http_filters/grpc_web_filter#config-http-filters-grpc-web) that allows a gRPC-Web client to send requests to Envoy over HTTP/1.1 and get proxied to a gRPC server. It’s under active development and is expected to be the successor to the gRPC [bridge filter](https://www.envoyproxy.io/docs/envoy/v1.27.0/configuration/http/http_filters/grpc_http1_bridge_filter#config-http-filters-grpc-bridge).

This seems to imply that a) the [`GrpcWeb`](https://www.envoyproxy.io/docs/envoy/v1.27.0/configuration/http/http_filters/grpc_web_filter) filter is not production-ready yet and b) the [`grpc_http1_bridge`](https://www.envoyproxy.io/docs/envoy/v1.27.0/configuration/http/http_filters/grpc_http1_bridge_filter) filter should be used in the meantime.

A number of external examples, notably [grpc/grpc-web](https://github.com/grpc/grpc-web/blob/master/net/grpc/gateway/examples/helloworld/envoy.yaml) use the `GrpcWeb` filter, suggesting that it _is_ production ready.

It would be helpful if the Envoy documentation could:

* Clarify the "active development" status of the gRCP-web filter, ideally linking to a tracking issue or similar resource
* Clarify the "production-ready" status of the gRPC-web filter, namely whether "expected to be the successor" is still correct
* Draw a clearer distinction between the two filters, notably what the gRPC-web filter does that the bridge filter does not (or vice versa), and clarifying whether the bridge filter needs to be used alongside the gRPC-web filter in any circumstances, or if the latter is a strict superset of functionality