grpc_http1_bridge sets HTTP status incorrectly for Trailers-Only responses

*Title*: grpc_http1_bridge sets HTTP status incorrectly for Trailers-Only responses

*Description*:

gRPC responses may optimize and put would-be-trailers in the headers frame if there are no data frames. The gRPC spec refers to this a a "Trailers-Only" response.

That is, the following two gRPC responses should be considered equivalent:

```
# normal
HEADERS
- END_STREAM
+ END_HEADERS
:status: 200
content-type: application/grpc
trailer: Grpc-Status
trailer: Grpc-Message
trailer: Grpc-Status-Details-Bin

HEADERS
+ END_STREAM
+ END_HEADERS
grpc-message: requested-error
grpc-status: 1
```
```
# Trailers-Only
HEADERS
+ END_STREAM
+ END_HEADERS
:status: 200
content-type: application/grpc
grpc-status: 1
grpc-message: requested-error
```

However, the `grpc_http1_bridge` does not treat them as equivalent. The bridge attempts to set the HTTP status code based on the `grpc-status` code; however, when doing so it it only looks for `grpc-status` in trailer frames; so it doesn't find it for a Trailers-Only response. And so, for the "normal" response, the bridge correctly sets the downstream HTTP status to 503, while for the "Trailers-Only" response, it erroneously sets the downstream HTTP status to 200.

*Repro steps*:

Put the `grpc_http1_bridge` in front of a gRPC server that performs the Trailers-Only optimization (in Go, `google.golang.org/grpc.Server.Serve` does this optimization, but `google.golang.org/grpc.Server.ServeHTTP` does not). Arrange for that server to respond with a non-zero `grpc-status`. Send an HTTP/1 request through the bridge. Observe that the HTTP status code is 200.

*Notes*:

The bug is plainly visible in `source/extensions/filters/http/grpc_http1_bridge/http1_bridge_filter.cc`. For reference the `grpc_json_transcoder` has a reasonably elegant solution to this problem.