Ability to use a single interceptor for both unary and streaming RPCs

[jhump]

After #1801 is completed, it becomes possible for a stream interceptor to be used when processing unary RPCs.

This issue is a feature request for some new API that allows for exactly this. The existing API, for backwards compatibility, will continue to register a stream interceptor that is only used for streaming RPCs. But a new method/dial option could be added that allows for registering a stream interceptor that is used for unary RPCs and/or for both streaming and unary RPCs.

[dfawley]

I'd like to redesign our interceptor API. Please add your list of requirements/nice-to-haves in this bug and I'll compile them here:

Requirements:

• Single interceptor type for unary and streaming
  • If it's difficult to implement, provide an optional convenience wrapper to generate a stream-style interceptor from a single function (like how unary interceptors work today).
• Include access to ServiceDesc/FileDescriptorProto (#1526)
• Chainable / able to easily register multiple handlers

Nice to Haves:

• Single API for stats handlers and interceptors
• Global registration pattern
• Able to specify via CallOptions
• Function signature includes explicit context.Context (from @skipor)
• Same/similar type signature as RPC handler itself (Java does this)

This is currently just a quick list based on my memory at the moment. I intend to add to this as I run into more things.

This will be a breaking change (breaking only features marked "EXPERIMENTAL" in the docs), but we will make sure to leave the current version around for one or two releases to allow time for users to migrate. We will also be sure to make a gRFC proposal for this.

[skipor]

Nice to Have, for Interceptors redesign: extract context.Context from ServerStream and pass it as the first argument in stream interceptor.
Now every context.Context wrapping requires also ServerStream wrapping, which is too complex. In my experience Context wrapping with value or timeout is a very common pattern, and it would be really nice to use it as everywhere else.