Improve gRPC status code mapping

Whenever Envoy sends a local response to a gRPC request, the returned grpc-status value is mapped from a HTTP status using httpToGrpcStatus(). This is used, for example, when an upstream request times out. In this case Envoy maps the internally used HTTP status code 504 (Gateway timeout) to gRPC status code SERVICE_UNAVAILABLE.

httpToGrpcStatus() is based on https://github.com/grpc/grpc/blob/master/doc/http-grpc-status-mapping.md, which states:

This table is to be used only for clients that received a response that did not include grpc-status.

I.e., the described mappings should be used only in case a gRPC client receives a non-gRPC response from a HTTP proxy.

Envoy is currently aware of gRPC requests, and supports deriving upstream request timeouts from grpc-timeout header in gRPC requests. In a case of an upstream request timeout gRPC status code DEADLINE_EXCEEDED might be more proper than SERVICE_UNAVAILABLE, depending on the reason of the timeout. For example, if upstream connection cannot be established SERVICE_UNAVAILABLE could be the proper status to return. If the connection can be established and request is successfully sent, then maybe the proper status to return is DEADLINE_EXCEEDED.

Finally, https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md contains a section on how to map HTTP2 stream errors (RST_STREAM frames) into gRPC error codes. This should be implemented as well.

Since there is no complete 1:1 mapping between HTTP and gRPC status codes it might be advantageous to use an internal enumeration of reasons for local HTTP responses and then have separate mappings from that to both HTTP and gRPC status codes.