Verify processing of stream control frames after reset

[huitema]

This PR tests three kinds of events that can involve "Reset Stream", "Max stream data" and "Stop Sending" frames processed after a stream has been reset or otherwise closed:

• processing the ACK of a packet that contained the frame, because the ACK may be received after the reset after the stream context was deleted,
• receiving extra copies of the frames after the stream is deleted. These extra copies shall be ignored with no side effect.
• processing of frames in packets detected as lost after the stream was deleted. The stack queries whether the packets needs to be repeated.

The combination of "ack/extra/need" with three frame types produces 9 possible tests. However, there is no acking processing for stop sending frames, so we do not implement a test for "ack of a stop sending frame.

Issue #1597 describes one such event: the stack tries to process the acknowledgement of a "reset stream" frame after the stream has been deleted. This issue is fixed in this PR, along several similar issues detected by the new tests.

Close #1597

[TimEvens]

@huitema , thanks for getting this fix in so quickly