Support directly invoking RPC handler implementation

[jhump]

Currently, the transcoder always rewrites the http.Request and also rewrites the response via decorating http.ResponseWriter. This involves copying the bytes at best and re-writing them at worst (i.e. to transcode messages to an alternate format). But if the handler that receives the rewritten request is an RPC handler, that will just up de-serializing the bytes in-process, then it would be more efficient if the transcoder could directly invoke the RPC handler's methods, passing it de-serialized messages without needing to copy or re-write the bytes.

This is currently feasible if the RPC handler is a grpc-go handler, registered with a grpc.ServiceRegistrar. This provides enough information to do direct method dispatch.

However, if the RPC handler is a connect-go handler, there is not sufficient information to do direct method dispatch. Such dispatch would either require additional generated code or require updates to protoc-gen-connect-go to make extra metadata available (including the service implementation itself).

This would also require an alternate way to construct a *vanguard.Service, providing it the actual implementation whose methods are invoked. It also requires substantial refactoring of the internal implementation to split the two sides of transcoding. They are currently already split into separate "client-side" protocol implementations and "handler-side" implementations, but they must be divorced further to support a case where the "handler-side" does not speak in terms of *http.Request and http.ResponseWriter at all, but is an interface that receives de-serialized messages.