Improve handling of stream ID exhaustion

[HTTP/2 spec](https://tools.ietf.org/html/rfc7540#section-5.1.1) limits the number of stream identifiers to 2^30, which means a channel must create a new transport once the limit is reached.

A couple of challenges with the current implementation:
- The exception "UNAVAILABLE: Stream IDs have been exhausted" is thrown, making the current RPC fail.
- A new transport is only created once all RPCs are complete, which is a problem for slow RPC and long lived streams, as there's no upper bound for how long a stream can live.

The implication here is that a channel can become unavailable for a unbounded amount of time. Here's a couple of possible improvements:
1. Forcefully cancel active RPCs so that the transport can shutdown quickly and completely so that a new transport can be opened. This is somewhat consistent with the current behavior where RPCs fail due to Stream ID exhaustion, but is still suboptimal with the same set of problems the current implementation has with failing RPCs. Given that a client already has to deal with various error situations, this could be a good enough solution.
2. Start new transport without waiting for the current transpot to shut down. This has a worst case scenario of creating a transport per long lived stream per ~1 billion requests, which is perhaps rarely enough given that a few thousands requests per second should last a few days.

See background discussion on https://groups.google.com/d/msg/grpc-io/GfeL3lse6lM/PZ-cy8qkAwAJ

実装ファイル、テスト、エントリーポイントのいずれも指定されていません。まず、HTTP/2 ストリーム ID の枯渇に対する Java のトランスポート処理を特定し、次に、提案されているトランスポートライフサイクルのアプローチのうち、どれが意図されたものかを明確にしてください。現在の RPC の動作を未定義のままにせず、チャネルの停止が無期限に続くことを回避できれば完了です。

索引モデルが issue の本文から書いたものです。