fix: Propagate EncoderBuilder's setting of block_checksum

[jshearer]

It appears that when BlockChecksum was originally introduced, the setting on EncoderBuilder never got passed down into LZ4FPreferences, resulting in errors like this. In this case, it's Go's lz4 library throwing the error:

lz4: invalid block checksum: got a1d59126; expected e48f521c

I confirmed that applying this patch locally fixes all of the invalid block checksum errors. I didn't have time to dig deeper into why this error was happening in the first place -- I would expect it to just result in the block checksum flag being turned on, and correct block checksums to be emitted, but somewhere along the line that appears to not be working correctly. Nevertheless, I believe this change fixes the ability to enable/disable block checksums correctly.

[pmarks]

@jshearer interesting, thanks for the report. This changes ends up changing BlockChecksums to be off by default. So presumably that's why you don't see the problem in Go. I'm going to take this patch, but also change the default to be BlockChecksums ON, because that is the current behavior of the library. With that change you'll be able to disable checksums in the builder to fix the issue you're seeing in Go. I'll investigate the further.

[pmarks]

lz4-rs has been setting the BlockChecksum during encoding. This checksum is always tested during decompression, and we haven't seen any errors. That makes me suspect that the bug is actually in the go lz4 impl, since the default for lz4 in general is to not do block checksumming. I'm superseding this PR with #55 which keeps BlockChecksum ON by default, but will actually switch it off if you disable it in EncoderBuilder.

[jshearer]

That makes me suspect that the bug is actually in the go lz4 impl

I think you're right, as I tested this with lz4_flex as well and got the same error (once I turned on block checksumming since it's off by default like you said) so I don't think this EncoderBuilder issue is causal. Probably good for it to be on by default at least from an "exercising surface area" perspective, if not necessarily a performance perspective.