Avoid using object pinning in native blackhole

[fzhinkin]

Re-implemented native blackhole without using object pinning as it affects performance and leads to unstable results as each time GC has to spend more and more time scanning all pinned values.

Instead, primitive values consumption is implemented as a comparison of the value for equality with two fields and publishing the value in case when comparison succeeds. The values themselves are never the same and one of the fields is volatile, thus the condition is always false and it could not be omitted because of volatility. That should prevent both dead code elimination and movement of the code computing the consumed value into an effectively unreachable branch.

For the objects, identifyHashCode is used to obtain an int-value that is then passed into a regular consumption routine. That function is an intrinsic that simply gets an address of the object, so it has no performance impact, yet it requires an object.

Verified stability and correctness using the reproducer mentioned here: #114 (comment)

With old implementation of the blackhole results looked like this:

… org.example.SampleBenchmark.explicitBlackholeBoolean
Warm-up #0: 479.799 ops/ms
Warm-up #1: 199.445 ops/ms
Warm-up #2: 153.165 ops/ms
Iteration #0: 129.017 ops/ms
Iteration #1: 109.637 ops/ms
Iteration #2: 95.7437 ops/ms
Iteration #3: 84.6977 ops/ms
Iteration #4: 76.3860 ops/ms
Iteration #5: 69.5794 ops/ms
Iteration #6: 63.7696 ops/ms
Iteration #7: 58.6253 ops/ms
Iteration #8: 54.5784 ops/ms
Iteration #9: 51.2170 ops/ms
  Success:   ~ 79.3251 ops/ms ±19%

With the new one:

… org.example.SampleBenchmark.explicitBlackholeBoolean
Warm-up #0: 39,150,009 ops/sec
Warm-up #1: 39,265,838 ops/sec
Warm-up #2: 39,308,961 ops/sec
Warm-up #3: 39,292,757 ops/sec
Warm-up #4: 39,212,672 ops/sec
Iteration #0: 286,605,538 ops/sec
Iteration #1: 285,862,297 ops/sec
Iteration #2: 287,091,192 ops/sec
Iteration #3: 287,978,046 ops/sec
Iteration #4: 285,223,227 ops/sec
Iteration #5: 287,148,384 ops/sec
Iteration #6: 287,206,388 ops/sec
Iteration #7: 287,319,456 ops/sec
Iteration #8: 286,483,907 ops/sec
Iteration #9: 288,042,045 ops/sec
  Success:   ~ 286,896,048 ops/sec ±0.19%

Fixes #114

[fzhinkin]

Well, there's a critical flaw in asm-based implementation: even though the native no-op function with inline assembly will be inlined into a benchmark, it's still a native call and its thread state transitions will surround inlined body (that's two CASes in total + potential runtime call, which undermine the whole idea). So I'll rewrite it using Kotlin-only solution.

[qwwdfsad]

Nice job!

[whyoleg]

@fzhinkin could you update benchmark results in PR description with latest changes?
Also overall full description could be updated and summarised based on comments, as implementation now is different as to what is proposed initially (just for future readers :) )