HPPCRT-33: Adopt perfomance enhancements found in fastutil 6.6x and Koloboke

[vsonnier]

Shamelessly steal the following performance optimizations from Fastutil 6.6x and Koloboke:
-- Replace MurmurHash3 scrambling by phiMix from Koloboke,
-- Unroll some fast-paths in some Hash methods for faster searches.

Study their actual performance gain, maybe also update the Caliper benches to JMH taking example on
java-performance.info benchmarks ( #27)

[vsonnier]

From fastutil / Koloboke:
-- Add partial unrolling in contains() / get() calls
-- Adopt PhiMix from scrambling anything primitive (which includes IdentityHash and CustomHash) but PhiMix appears clearly bad on Objects, as revealed by the BAD hash use case. Execution times can plumet in the order of 10x normal. Clearly visible is HPPC_OBJ vs. FASTUTIL_OBJ (fastutil 6.61) cases.
So keep Murmurhash3 to scramble Object.hashCode().

General performance improvement rank from 10 to 20 % compared to v0.67 using a proper JMH-based test suite:
https://github.com/vsonnier/hppc/tree/0.65.x-RT-release/hppcrt-benchmarks/src/main/java/com/carrotsearch/hppcrt/jmh

[vsonnier]

OK I really have too much free time:
Try new possible enhancements, including Fastutil fastpaths "assignement-in-expressions" kinds, (KType, VType=KType) packing in single array a la Koloboke. The later is finally quite simple to implement using partial template specializations again. (C++ solved it all)

[vsonnier]

If (KType, VType=KType) packing in single array eventually proves itself good, it will also mean another
breaking compatibility change: In this case, completely remove for hashmaps the public access of uderlying array(s).
In practice, they will indeed no longer be in any simply understandable format. (especially if I pack several (K,V) on longs, in case of primitives)
There is no pratical performance problem here, since the forEach() construct has now the same speed
that a direct iteration.

[vsonnier]

Mmm. Well after much head scratching, I came up with this and also this uber change of the TemplateProcessor: Indeed, include-like are now possible in the form of a custom Velocity directive "#import". This allows really cross-module inclusion, currently for inlining purposes of Intrinsics.java, now an ordinary file which deserves no special management in the TemplateProcessor.

Note that I'm by no means closer to template specializations. I'm actually dropping the subject completely because it is not worth the fatigue: I'm no going to support, i.e maintain and test tens of specializations for another marginal gain, while turning the maintainance into a nightmare. I give up.
Only remains "assignement in expressions" to investigate, and also serious stuff like fixing actual bugs.

[vsonnier]

Considered done in
a807de7