ASGI RPC errors that occur after the first response is sent in streaming handlers lead to runtime errors rather than an non-0 status response

[willjschmitt]

The asgi _do_grpc_error handler writes out the failing status as a header and an asgi http.response.start event. If a streaming RPC has already emitted a response (via an http.response.body event), writing another http.response.start event is invalid and causes runtime errors in at least uvicorn. I think it might be a better approach instead to always write out the status as trailers, and do it in a common way, so that the status is always just written out regardless if the status is ok or not, which would work for both unary/streaming as well as ok/non-ok statuses, with the caveat that failures that occur before headers are emitted need to emit at least the headers before the trailers can be written, since trailers are just body content. It could be worth considering using the http.response.trailers event, but that's an asgi extension and not universally supported in ASGI servers, so it's probably not worth multiple implementations based on the server extensions provided in the scope