[STORE]: Make use of Lucene build-in checksums

Since Lucene version 4.8 each file has a checksum written as it's
footer. We used to calculate the checksums for all files transparently
on the filesystem layer (Directory / Store) which is now not necessary
anymore. This commit makes use of the new checksums in a backwards
compatible way such that files written with the old checksum mechanism
are still compared against the corresponding Alder32 checksum while
newer files are compared against the Lucene build in CRC32 checksum.

Since now every written file is checksummed by default this commit
also verifies the checksum for files during recovery and restore if
applicable.

Closes #5924

Note: This PR still has a bunch of nocommits and I need to crank up some more bwcompat tests but I wanted to get the word out... all tests pass
so the problem here is actually that I need `some` way to mark that this shard is corrupted. I can write a `__corrupted__` file instead of renaming them but the problem is that if I I have a scenario with 1 replica and the then I expand to 2 replicas and the primary is corrupted we fail the primary and then the first replica that is NOT corrupted will take over as the primary. Once this happens the cluster can allocate a replica on the node where the corrupted primary used to life and bring back the corrupted shard since it just reads the checksums form the files and realises that nothing needs to be copied. IMO we need to prevent this situation @kimchy this is actually the reason for the mark as corrupted... If you guys have better ideas please lemme know