Support for using non-protobuf message types or alternate codec

[jhump]

gRPC can support non-protobuf messages via custom codecs. It can also support protobuf messages while using a different on-the-wire representation via custom codecs (such as using JSON on the wire).

Ideally, grpchan would provide the same support. The core Channel and ServiceRegistry abstractions are fine how they are, but the actual implementations in the httpgrpc and inprocgrpc packages are what need to change.

For in-process gRPC, we actually don't want any on-the-wire representation, but instead try to do an efficient copy. Copying is necessary since bad things can happen if client and server goroutines are trying to use the same message instance concurrently, from different goroutines. But marshaling to bytes and back is likely slower and less efficient than just copying Go data structures. So this can be adequately handled in the inprocgrpc package by supporting custom logic for copying/clone messages (related: #19).

The httpgrpc package, however, needs a way to handle alternate encodings. It currently assumes protobuf, even requiring it as the content-type for unary RPCs. So a "v2" of the wire format for gRPC-over-HTTP-1.1 would need to behave more like "real" gRPC, where the codec type is a suffix of the content-type. The server could even support multiple codecs simultaneously by registering different codecs with different content-type suffixes (so some clients could use proto binary format and others could use JSON, for example).