This patch fixes two issues with HPACK desync. The first one appears
when we encode trailer headers at the moment of encoding regular headers
For example: Tempesta encoded headers and trailers and proceed to
sending the body. During sending the body scheduler few times preemt
the current stream to send headers for another stream, therefore HPACK
dynamic table contains the new headers and indexes used for trailers are
invalid. To fix this we decided to not use HPACK dynamic table for
trailers, it is a good trade-off between complexity and efficiency.

The reason of the second is not sending new size of the dynamic table
in trailer HEADERS frame. When client advertised the new size of the
dynamic table Tempesta must respond with selected size in the first
HEADERS it doesn't matter whether they are trailers or regular headers.

Small refactoring to improve readability

By the standart during sending headers block any others frames are
forbidden except CONTINUATION frame

Before this patch Tempesta stopped to send headers block when
RST_STREAM frame was received or sent, that broke HPACK state. In
this patch we sending all encoded headers to maintain synchronized
HPACK dynamic table.

The case when Tempesta receives obviously broken HEADERS or PRIORITY
frame Tempesta treats it as suspicios and do disconnect instead of
handling this case with RST_STREAM. It looks that it doesn't makes
sense to continue service this connection. Also this removes the attack
vector for RST_STREAM flood.

RFC 9113 5.4.1. Connection Error Handling:
An endpoint can end a connection at any time. In particular, an endpoint
MAY choose to treat a stream error as a connection error.

Do this to ensure that the function calculating frame size accounts for
the dynamic table size, not just the headers, and does not produce
CONTINUATION frame if the data fits within a single HEADERS frame.

The main reason to fix this:
It seems firefox has a bug because of that it can't proccess
CONTINUATION frame for closed stream and resets connection breaking
page loading.

The function must have only one responsibility insert frame headers,
however before this patch it also sent data. In this patch we
extract data sending logic into dedicated state to make code more
understandable and explicit

This patch enables splitting HEADERS and CONTINUATION frames according
to the maximum frame length and sends the resulting frame fragments
as the sending window becomes available. Length of prepared frame stored
in `TfwHttpXmit` struct. This avoids generating a large number of
small CONTINUATION frames, which may be rejected by some
implementations, such as nghttp.

This is a similar optimization to the one used in the previous framing
implementation. However, this version enforces the minimum sending
budget only for the TCP send window, not for the HTTP/2 flow-control
window. This allows to send small DATA frame and proceed to the next
stream if TCP window is available.

In addition, this patch no longer stops re-scheduling when a stream's
flow-control window is exhausted. Instead, it continues searching for
the next stream with available window capacity.

According to the HTTP/2 specification, when two or more
`SETTINGS_HEADER_TABLE_SIZE` values are received between header blocks,
the receiver must send at most two dynamic table updates. These updates
must include the minimum received and applied value and the currently
applied value.

The minimum applied value is needed for the sender of the setting
`SETTINGS_HEADER_TABLE_SIZE` to perform the same eviction in the
decoder’s dynamic table.

`tfw_hpack_enc_tbl_write_sz()` is a part of framing, it is not a part of
hpack implementation