Add protocol handshake to 'READY' connectivity requirements

When security is disabled, not waiting for the HTTP/2 handshake can lead to
DoS-style behavior.  For details, see:
grpc/grpc-go#954.  This requirement will incur an
extra half-RTT latency before the first RPC can be sent under plaintext, but
this is negligible and unencrypted connections are rarer than secure ones.

Under TLS, the server will effectively send its part of the HTTP/2 handshake
along with its final TLS "server finished" message, which the client must wait
for before transmitting any data securely.  This means virtually no extra
latency is incurred by this requirement.

Go had attempted to separate "connection ready" with "connection successful"
(Issue: grpc/grpc-go#1444 PR:
grpc/grpc-go#1648).  However, this is confusing to
users and introduces an arbitrary distinction between these two events.  It has
led to several bugs in our reconnection logic (e.g.s
grpc/grpc-go#2380,
grpc/grpc-go#2391,
grpc/grpc-go#2392), due to the complexity, and it makes
custom transports (grpc/proposal#103) more difficult
for users to implement.

We are aware of some use cases (in particular,
https://github.com/soheilhy/cmux) expecting the behavior of transmitting an RPC
before the HTTP/2 handshake is completed.  Before making behavior changes to
implement this, we will reach out to our users to the best of our abilities.

doc/connectivity-semantics-and-api.md

@@ -23,9 +23,10 @@ make progress on one of the steps involved in name resolution, TCP connection
 establishment or TLS handshake. This may be used as the initial state for channels upon
 creation.
 
-READY: The channel has successfully established a connection all the way
-through TLS handshake (or equivalent) and all subsequent attempt to communicate
-have succeeded (or are pending without any known failure ).
+READY: The channel has successfully established a connection all the way through
+TLS handshake (or equivalent) and protocol-level (HTTP/2, etc) handshaking, and
+all subsequent attempt to communicate have succeeded (or are pending without any
+known failure).
 
 TRANSIENT_FAILURE: There has been some transient failure (such as a TCP 3-way
 handshake timing out or a socket error). Channels in this state will eventually
@@ -52,8 +53,8 @@ immediately. Pending RPCs may continue running till the application cancels them
 Channels may enter this state either because the application explicitly requested
 a shutdown or if a non-recoverable error has happened during attempts to connect
 communicate . (As of 6/12/2015, there are no known errors (while connecting or
-communicating) that are classified as non-recoverable) 
-Channels that enter this state never leave this state. 
+communicating) that are classified as non-recoverable)
+Channels that enter this state never leave this state.
 
 The following table lists the legal transitions from one state to another and
 corresponding reasons. Empty cells denote disallowed transitions.