REGTESTS: compression: check hard to compress contents and nearly full buffers

REGTESTS: compression: check hard to compress contents and nearly full buffers

Add reg-tests/compression/output_margin_*.vtc, with a Lua service in
output_margin.lua, which sends bodies that are incompressible or barely
compressible (random bytes, bytes that cost 9 bits each with the fixed
tree, random data mixed with text, random data with short matches, runs
of 9-bit literals separated by 4-byte matches) or repetitive. The service
serves the cases of the set named in the request in order, so that the
vtest clients just loop over the same request. Each response must be
compressed with gzip, and is decompressed by the client, which checks the
gzip trailer's CRC and length, then compares the body length to the one
announced in x-len.

The tests are split into several files so that vtest runs them in
parallel, and tagged slow:
  - output_margin_{whole,buf,small,odd}.vtc send all patterns through 4 kB
    buffers, whole or by calls of 4000, 1 to 64 or 1 to 20000 bytes;
  - output_margin_full_{random,run51}.vtc use 16 kB buffers and
    tune.maxrewrite 32, so that the buffer may be almost full when the
    filter compresses it, with bodies of 16088 to 16116 bytes sent in one
    call. With the default maxrewrite, the channel always keeps far more
    room than the deflater could ever need, which is why this does not
    happen with default settings. These sizes still leave enough room for
    the deflater, so they must be compressed as well (responses of 16144
    bytes or more are not compressed at all with this setup).

Before the fixes, the last two crashed haproxy in comp_http_payload()
(htx_get_blk_type() on the NULL block returned by htx_replace_blk_value())
for all sizes from 16086 to 16118 bytes, which is the crash reported since
3.5-dev10. Each file takes about as long as a trivial test (0.25 to 0.3s
without ASAN here, 0.33 to 0.42s with ASAN).