Redesign how frames are written.

There's now three goroutines per connection, plus one goroutine per
active http.Handler. The base three are:

1) the "serve" loop coordiantor that owns most state about a conn and
   never blocks.
2) the readFrames loop, blocked reading from the network to read more
   frames from the peer.
3) the writeFrames loop (this one is new), which might also get blocked,
   writing faster than the peer can receive frames.

The http.Handler goroutines now tell the first goroutine (the serve
loop) that they would like a frame written. The serve goroutine acts
as the frame scheduler, deciding how to send frames based on
priorities. It can also stop reading from its channel, causing
pushback to the handlers if they're sending too much. But in practice
the handlers will do their own pushback, since each frame write
request includes a channel to be notified of when it's actually
written. Handlers writing response data, for instance, will wait until
their data is written (especially when they're out of flow control
tokens) before trying to send more.

For now the scheduler is naive, but the design feels right now.