Use a `Sink` argument instead of returning a `Stream` for response streaming

## Feature Request

Love the project! Just one request on response streaming.

Most (because I haven't used all of them) gRPC implementation passes a `sink/writer` handle into the handler stub. In the stub implementation, users may call `sink.send(response)` or `write.write(response)` to stream data to the client. However, `tonic` makes the handler return a `Resonse` type.

This has two issues
1. This usually leaks `tokio::spawn` handles; or that user needs to build special apparatus to keep track of these handles.
2. We exit `Layer`s before stream is completed

### Crates

I think just `tonic`?

### Motivation

1. stream back from inside the handler, instead of a stray tokio task
2. able to have more control over streaming response in `Layer`s. -- concurrent stream limits, response coalescing, etc.

### Proposal

TBD

### Alternatives

* maybe `tonic` runtime can take a join handle in the handler return value and wait for the task to finish before exiting the layers? Less powerful then `Sink` interface but solves the control issue in `Layer`