Keep define-dependent GC code from falling through the cracks #88

The upstream review of the big-blocks regression showed how GC configuration bugs slip through. HaxeFoundation/hxcpp#1402 narrowed the row counters with a type that was right for default blocks and wrong for big blocks, and the test suite still passed with big blocks; only a compile-time check catches that. HaxeFoundation/hxcpp#1413 then stopped big blocks from compiling, unnoticed because no build used it, and it went to master directly. HaxeFoundation/hxcpp#1417's define-dependent row type broke HXCPP_GC_BIG_BLOCKS with HX_GC_VERIFY_ALLOC_START, and every HXCPP_GC_DEBUG_LEVEL, with CI green; HaxeFoundation/hxcpp#1393 broke HXCPP_GC_DYNAMIC_SIZE the same way. A PR was also merged over a CI failure because master failed the same way.

libhxcpp already compiles Immix.cpp under 32 define combinations at both block sizes, static-asserts the row-count types, traps out-of-range counts in debug builds, and (with #85) runs eight GC modes. Still open:

• Prefer one form of code in every configuration when the cost is negligible (one row-count type, not one per block size), and write that down as a contribution rule.
• A new or documented define gets CI coverage when it lands: in the compile check, and in a run where it changes behaviour. Every define in docs/build_xml/Defines.md should be built somewhere.
• The define check only syntax-checks Immix.cpp with g++. GcCommon.cpp, the GC headers and the cppia GC paths are not checked, and MSVC and clang are not used.
• Combinations that are never run: big blocks with generational or verify, HXCPP_GC_DYNAMIC_SIZE, HXCPP_GC_NURSERY, the debug levels, HXCPP_SINGLE_THREADED_APP.
• No sanitizer builds (ASan, UBSan, TSan) run the GC tests.
• Known CI failures are tracked as issues and fixed, never merged around.

Related: HaxeFoundation/hxcpp#1409, HaxeFoundation/hxcpp#1392, #87.