Investigate LZ4 filter compatibility

[derobins]

@epourmal says that the LZ4 filter is not a direct LZ4 compression filter, but instead adds extra bytes to the buffer, which makes it difficult to extract chunks and decompress them directly.

[mkitti]

There is indeed a 12-byte header where the decompessed size and block size are stored as 64-bit and 32-bit big endian integers:

hdf5_plugins/LZ4/src/H5Zlz4.c

Lines 207 to 218 in c1e11d3

	rpos = (char*)*buf; /* pointer to current read position */
	roBuf = (char*)outBuf; /* pointer to current write position */
	/* header */
	i64Buf = (uint64_t *) (roBuf);
	i64Buf[0] = htobe64t((uint64_t)nbytes); /* Store decompressed size in be format */
	roBuf += 8;
	i32Buf = (uint32_t *) (roBuf);
	i32Buf[0] = htobe32t((uint32_t)blockSize); /* Store the block size in be format */
	roBuf += 4;
	outSize = 12; /* size of the output buffer. Header size (12 bytes) is included */

A more standard approach would have been to the LZ4 frame format which can optionally encode the decompressed size:
https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md

I suggest supporting the standard frame format by checking for the little endian magic key, 0x184D2204 as documented in the frame format above. While it is possible that these four bytes could be part of an 8-byte big endian integer value indicating a very large chunk on the order of 0x04224d1800000000, a few hundred exabytes, I think it may be possible to employ some heuristics to distinguish these two possibilities.