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.