frame_creator:create_frame_headers_frame abstraction is wrong for draft 13+

[LPardue]

frame_creator.c includes this:

/*
 *  0                   1                   2                   3
 *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 * |                    Optional Push Stream Header                |
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========
 * |           Length (i)       ...|    Type (8)   |   Flags (8)   |  Frame HDR
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========
 * |                        Header Block (*)                       |  HEADERS
 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Payload
 */

This was never a valid abstraction but it worked ok. However, with the changes that were made in HTTP/QUIC draft 13 this crutch makes life difficult.

We need to separate out unidirectional stream headers from the following frames or extension defined data that will be sent thereafter.

[LPardue]

For reference, my changes on the uni-stream-types-and-usp branch demonstrate one way of getting this to work.

Realistically, we'd want to incorporate unidirectional stream types during an uplift to a newer QUIC draft, then USP could sit on an experimental branch longer term.