don't use the control frame queue for stream-related frames

[marten-seemann]

Stream-related frames (MAX_STREAM_DATA, RESET_STREAM, STOP_SENDING, STREAM_BLOCKED) could be enqueued with their respective stream instead of using the control frame queue. The control frame queue is an incredibly mindless tool: It doesn't remember any context of the frames, it just queues and dequeues them, oblivious to what's happening around.

Queueing the frames at their respective stream would allow us to optimize frame handling, e.g.:

• send out a fresh MAX_STREAM_DATA frame (i.e. with an updated offset) if one is lost
• not send out a MAX_STREAM_DATA frame if there are still a few (>= 2 maybe) in flight
• not send out control frames if the stream state changed (e.g. there's no need to send a STREAM_BLOCKED frame if the peer sent us a STOP_SENDING)
• (de-) prioritize sending of control frames for certain streams (this probably is a terrible idea)

It would also allow us to delay garbage collecting of the stream until all relevant control frames for that stream have been acknowledged. To be clear, we can garbage collect the stream if there are still MAX_STREAM_DATA frames outstanding, and we would now know that losing these frames would be a no-op.