get rid of std::hash

[lll-phill-lll]

As was noted by @vladl2802 in #11416 we have non even distribution of values between buckets while spilling.

The root couse of it is that we rely on a hash function here:

ydb/yql/essentials/minikql/comp_nodes/mkql_wide_combine.cpp

Line 489 in 6dac5e0

auto bucketId = hash % SpilledBucketCount;

which appears to be std::hash which just returns the value itself: https://godbolt.org/z/es8dxMGeY

Hash function is set here:

ydb/yql/essentials/public/udf/udf_type_ops.h

Line 44 in c8e6180

return std::hash<T>()(value.Get<T>());

As a temp measure we change the algorithm of bucket selection from hash%128 to XXHASH(hash)%128. pr: #11471

Also, with std::hash we can face compatibility issues while changing MKQL_RUNTIME version.

So, the proposal of this task is to change std::hash to some other hash function. Hash functions to consider:
rh hash:

ydb/yql/essentials/minikql/comp_nodes/mkql_rh_hash.h

Line 219 in c8e6180

ui64 bucket = ((SelfHash ^ hash) * 11400714819323198485llu) >> capacityShift;

xxhash: https://github.com/Cyan4973/xxHash. We already use xxhash in GraceJoin:

ydb/yql/essentials/minikql/comp_nodes/mkql_grace_join_imp.cpp

Line 78 in c8e6180

XXH64_hash_t hash = XXH64(TempTuple.data() + NullsBitmapSize_, (TempTuple.size() - NullsBitmapSize_) * sizeof(ui64), 0);

[lll-phill-lll]

Same problem we had in the hash shuffle algorithm for channels. We were trying to fix it here: #4364. But had to revert it because of the compatibility issues

[yumkam]

XXH3_64Bits (from same xxh library) claimed to provide better performance for small-inputs (I have not benchmarked it)