Content-Type missing in responses triggered by interceptors returning Status

## Bug Report

Services guarded by interceptors that return `Err(Status::*)` for any reason are missing `Content-Type` headers in the responses when queried with `grpcurl`.

### Version

Tested on the main `v0.6.1` release and the latest `master` branch

### Platform

`Linux plopear 5.14.16-arch1-1 x86_64 GNU/Linux`

### Crates

`tonic`

### Description

TL;DR: `Err(Status::*)` responses are handled differently when they occur in `Interceptor`s versus methods, leading `grpcurl` to complain that the `content-type` header is missing in `Interceptor`-generated responses.

Similar to #431, #700, and #759, but creating a new issue since this appears to be a broader case than a specific example not working (or represents a regression to the fix applied in #701).

I've created a repro of the issue [here](https://github.com/NAlexPear/tonic-interceptor-response-repro). This repro lets you configure different `FAILURE_MODE`s through environment variables: `None` means that there is no failure, `Method` means that the configured methods return a `Status`, and `Interceptor` means that the interceptor returns a `Status`. I'd expect `Method` and `Interceptor` failure modes to generate the exact same response, but they do not. Listed below are the tests I've run on each relevant failure mode.

**Failure Mode**: `Method`
**Run command** (in repro repo): `RUST_LOG=info FAILURE_MODE=method cargo run`
**Query command**: `grpcurl -plaintext -import-path ./proto -proto health.proto [::]:50051 grpc.health.v1.Health/Check`
**Query response**:
```
ERROR:
Code: Internal
Message: Failure within the Check method
```

**Failure Mode**: `Interceptor`
**Run command** (in repro repo): `RUST_LOG=info FAILURE_MODE=interceptor cargo run`
**Query command**: `grpcurl -plaintext -import-path ./proto -proto health.proto [::]:50051 grpc.health.v1.Health/Check`
**Query response**:
```
ERROR:
Code: Unknown
Message: OK: HTTP status code 200; transport: missing content-type field
```

The first is behaving as expected, the second is not.

### Next Steps:

I'll do a bit more digging to see how these requests are different, and I suspect that a fix like #701 will be in order. But want to make sure that this is floated as a possible regression on _all_ interceptors, rather than those used in a particular example.