Define Context semantics on client-side

`Context`'s semantics is quite clear on the server-side. For each call:
1. `ServerImpl` creates the base `Context`.
2. `ServerInterceptor`s can create new `Context`s, which can be based on the base `Context`. The last created `Context` is what the server application sees.
3. Server application access the `Context` from thread-local. And if it initiates outgoing calls, by default they inherit the `Context`.

For the client-side, currently the `Context` semantics is:
1. The current `Context` when `Channel.newCall()` is called is the base `Context`.
2. `ClientInterceptor`s create new `Context`s, which can be based on the base `Context`. The last created `Context` is what `ClientCallImpl` uses
3. `ClientCall.Listener` is called under the `ClientCallImpl`'s `Context`.

This is problematic. If a new call is made from the `ClientCall.Listener`, it will inherit the previous call's `Context`. If this chain of calls is unbounded, and every call goes through interceptor(s) that create `Context` based off the current `Context`, this will create an unbounded inheritance chain of `Contexts`. Because `Context` always keeps a reference to the parent `Context`, this will lead to memory leak.

`Context` is designed to work like a stack. The expectation is that a `Context` (except the background one) should eventually be popped out of the "stack". Infinite pushing without popping, like the case from previous paragraph, should not happen. IMO, this means `Context` should only be passed in one direction. On the client-side, the direction should be **application -> interceptors -> gRPC core**. Since `ClientCall.Listener` is the other direction, it should not be called under the top-most `Context`, but rather the `Context` that application sees, which is the pre-interceptors one. This will prevent the unbounded-Context-chain issue.