Fix super block compression and stream raw blocks in decompression

[terrelln]

Super blocks must never violate the zstd block bound of input_size + ZSTD_blockHeaderSize. The individual sub-blocks may, but not the super block. If the superblock violates the block bound we are liable to violate ZSTD_compressBound(), which we must not do. Whenever the super block violates the block bound we instead emit an uncompressed block.

This means we increase the latency because of the single uncompressed block. I fix this by enabling streaming an uncompressed block, so the latency of an uncompressed block is 1 byte. This doesn't reduce the latency of the buffer-less API, but I don't think we really care.

• I added a test case that verifies that the decompression has 1 byte latency.
• I rely on existing zstreamtest / fuzzer / libfuzzer regression tests for correctness. During development I had several correctness bugs, and they easily caught them.
• The added assert that the superblock doesn't violate the block bound will help us discover any missed conditions (though I think I got them all).

Credit to OSS-Fuzz.

[Cyan4973]

Note : it changes the meaning and role of dctx->expected.

Instead of being the amount of data of next block,
that a user must provide for decompression to happen,
it is now an indication of what it should provide, though less may also be authorized.
More importantly, this variable becomes a stage validator (it must be ==0 to move to next stage).

Nothing wrong with it, just, it's a fairly consequential change of meaning,
on a long-lived variable which is pretty close to global state,
so it deserves careful attention,
since there is a potential that it could mess with other parts of the code base where it's read or written.

[terrelln]

Fix the travis failure due to a missing ZSTD_DCtx_reset() call