Provide support to read/write lz4 frames

[harendra-kumar]

See this document for the lz4 container format: https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md .

We can write a parser/terminating fold to decode a stream of frames into a stream of compressed blocks and decode the frame header and then decompress appropriately using the options/flags in the frame header. Similarly write a serializer to write a stream of compressed blocks as a lz4 frame using options provided by user.

Also, we have to handle the following in the block headers:

• the uncompressed bit in the block header. Currently we error out in that case.
• blocks with block checksum following the block

[harendra-kumar]

In descending priority:

1. Support uncompressed block bit in the block header
2. Support checksum trailer after the block
3. Support frame decoding

[adithyaov]

To support lz4 frames the configuration should be extended to handle the following,

• Uncompressed size (See Make the combinators configurable #19)
• Checksum
• Meta data byte encoding format (Endianness)
• A way to determine the end of valid compressed data (I'll call it a resizeGuard)

Regardless of the configuration, we should support the following,

• Uncompressed bit (-ve uncompressed size). This might also require a few changes in the streaming combinators.

We need to be able to automatically determine the config when special combinators associated with lz4 frames are used. For this, the following needs to be done.

• Add a parser/fold to decode the frame header
• Add special combinators that assume a frame header at the beginning of the stream