BLOCKED frame.

I added a new issue for the blocked frame.

As a reminder, the expectation, based on our implementation experience, is
that flow control and other settings limiting state size are helpful, but
can cause issues with the user experience when tuned improperly, as these
settings invariably are...
Worse, finding bugs in flow control implementations is extremely annoying
and difficult without explicit signaling (Why did the client/server stop
sending us data? What is going on?!)

A BLOCKED frame helps with both of these issues:
When an endpoint is blocked on flow control, but the socket is writable, it
emits a frame saying so, and the remote end now has explicit signaling
about the tuning of the flow control size.
When you get a BLOCKED frame, if you didn't expect the other side to be
blocked (i.e. you believe the window isn't closed), you can log the fact
for investigation.

Flow control is the current most-common (and arguably the most important)
use for BLOCKED, but an endpoint can also be blocked on the max-concurrency
limit, e.g. 10 max connections for gmail. It would be extremely helpful to
know how often this is occurring so as to tune these parameters.

-=R