Unlocking features needed for a tonic based grpcmock library

## Feature Request

### Crates

* tonic-build
* tonic

### Motivation

At Emotech we've been using https://github.com/LukeMathWalker/wiremock-rs a lot internally for mocking our HTTP services. And now we're moving to a lot of gRPC for bidirectional streaming where services will generate things like audio and animation data. Given the complexity involved in streaming protocols we were looking for a similar solution to wiremock-rs for gRPC.

### Proposal

There is some prior art in this space https://github.com/Fadelis/grpcmock and I've attempted some initial implementation work (not currently public) to try and bring together a similar experience. However I've came up with a few roadblocks during my attempts. I'll attempt to summarise what I've tried and why it's failed. So this may end up a bit long.

My first thought was to create a MockServer type that takes in any HTTP2 request, matches the URI to one generated from the service definition and map that to the users supplied matchers/condition checkers.

For ones which rely on the message contents and send different responses based on that we'd use the `ProstCodec` to decode it and pass the input type into some lambda function which would either be synchronous or return a `Future`.

The path for API call is hard coded in the tonic_build output, this prevented the mapping from input request to the associated matcher easily.

Example of generated code:

```rust
fn call(&mut self, req: http::Request) -> Self::Future {
let inner = self.inner.clone();
match req.uri().path() {
"/tonic_mock.dummy.Mock/Unary" => {
```

Currently, I'm taking a step back and just thinking the best way is to just generate the server traits and provide a simple copy+paste implementation people can just plug into the generic traits or use a macro to generate the implementation automatically. But while I explore that I guess it's time to open an issue for discussion to see what thoughts are in this area :eyes: