ObjectMap is 20% slower than stock hxcpp 4.3.53 (map_object benchmark) #232

The benchmark suite (#151) measures ObjectMap at 0.8x the speed of stock hxcpp 4.3.53: 7.3M map operations/s against 9.2M (spread ±2.2% and ±2.8%, so the gap is outside the noise, but less clear-cut than map_int).

What the benchmark does (bench/src/MapBenchmarks.hx, MapObject): a fresh ObjectMap<MapKey, Int> with 200,000 class-instance keys created in setup(); 200,000 sets, 200,000 hits, 200,000 misses, 100,000 removes, then iterates the values left. Checksums match stock.

#77 doesn't explain it. On 64-bit every ObjectMap operation goes through GetObjectID's global mutex and table, but that's inherited from stock hxcpp (HaxeFoundation/hxcpp#679), so both runtimes pay it. Fixing #77 would probably make libhxcpp faster than stock here and hide this gap, so find what libhxcpp does differently first (object ID table, hash code, GC work for the ID table), then do #77.

Measured on perf/benchmark-suite at bf583e5, which includes the #230 heap fix: Windows, Ryzen 9 9950X, MSVC 19.44, 64-bit, Haxe 4.3.7, 3 processes x 10 samples. The full table is in that branch's README.

Reproduce (on perf/benchmark-suite until the suite reaches main):

cd bench
haxe --run Run --only map_object

Done when map_object is at least level with stock on Windows and Linux, measured before #77 lands.