disable XXH64 autovectorization

[Cyan4973]

using a compiler fence (like XXH32).

XXH64 has been reported to be auto-vectorized on AVX512 architecture (with recent clang compilers).
Like XXH32, it's generally a bad idea to vectorize XXH64. So disable it, using the same technique.

However, in order to test, or if the results differ for newer cpus, it's also possible to disable the fence by using XXH_ENABLE_AUTOVECTORIZE build variable.

fix #897

[Cyan4973]

@TocarIP : if you have the time,
it would be nice to test if this patch works as intended,
aka :

• before the patch, XXH64 is auto-vectorized with clang-trunk when AVX512 is enabled.
• after the patch, it no longer is vectorized, thus restoring performance to previous level
• when compiled with XXH_ENABLE_AUTOVECTORIZE, XXH64 is once again vectorized

It's difficult for me to access cpus with avx512 enabled, though I will try nonetheless.

[TocarIP]

I've patched this into zstd, and can confirm that everything is WAI. I haven't run benchmarks, just looked at the asm, but that should be enough, thanks for the fix!

[Cyan4973]

I could get access to some systems with AVX512 enabled : a Tiger Lake mini laptop, and a Zen4 NUC.
Both were running Windows 11. I employed msys2/mingw64 for compilation, and also WSL2+Ubuntu on the Zen4 NUC.

0. Checked that AVX512 was working properly, notably thanks to xxhsum welcome diagnosis message, and by checking performance of XXH3.
1. XXH64 could not be auto-vectorized on any configuration. gcc-13, clang-14 and clang-17 were used for these tests, and followed the recommended CFLAGS settings : -O3 -mavx512f -mavx512dq -mavx512vl. To no avail. Unless performance is strictly exactly the same across all hardwares and compiler versions, it simply never is auto-vectorized.
2. As a counterpoint, XXH32 could be auto-vectorized with clang, as expected. So auto-vectorization itself was active.
3. Auto-vectorization of XXH32 leads to lower performance on Tiger Lake, as expected, but improved performance on Zen4, which was more surprising. That's the first time I see vectorization bringing benefits to XXH32. It underlines that the topic is a bit more complex than "just disable it", and reinforce the need to offer a knob to let the user decide.
4. Checked on Godbolt that the GUARD was working as intended and preventing the compiler to generate vectorized code.
5. Checked that performance of XXH64 was unaffected by the GUARD on any configuration.

So the only disappointing part was the inability to get XXH64 auto-vectorized with AVX512, which I can't explain at this point. As a consequence, it may make this patch look kind of useless, since it prevents a scenario that apparently doesn't happen. But as @TocarIP reported that it works as intended, and since it doesn't introduce any negative performance side effect, I believe it's good to merge nonetheless.