Remove gc_bump_pointer_heap - #17731

The inline allocation fastpath for the default GC mirrors only the
cursor bump of ractor_cache_allocate_slot(), skipping two pieces of
bookkeeping that the interpreter always performs:

* heap_cache->allocated_objects_count is not incremented, so
  total_allocated_objects undercounts objects allocated from JIT code
  and GC.verify_internal_consistency crashes with "inconsistent live
  slot number". Reproducible on a dev_nodebug build with:
  ruby --zjit-call-threshold=1 test/ruby/test_array.rb \
    -n test_replace_wb_variable_width_alloc
  Incremental marking step pacing also reads this counter.

* RUBY_INTERNAL_EVENT_NEWOBJ hooks are bypassed entirely, so
  TracePoint/ObjectSpace tools miss objects allocated from JIT code.
  Reproducible with test/-ext-/tracepoint/test_tracepoint.rb
  -n test_tracks_objspace_count. Check ruby_vm_event_flags like
  rb_gc_event_hook_required_p() and take the slow path while NEWOBJ
  hooks are enabled, which is what the MMTk fastpath already does via
  newobj_tracing_p_func.

Both regressed in 583668d ("Remove gc_bump_pointer_heap", rubyGH-17731).
The original fastpath from rubyGH-17277 handled both cases: allocations
were counted from cursor movement ((cursor - region_start) / slot_size),
which included JIT inline allocations, and a dedicated jit_cursor_end
window was kept closed by gc_ractor_jit_cursor_sync() while NEWOBJ
hooks were enabled. rubyGH-17731 switched counting to an explicit
allocated_objects_count++ that only the interpreter performs, and
removed jit_cursor_end without a replacement for the hook check.

Note that this fastpath is compiled out on RUBY_DEBUG builds because
of RACTOR_CHECK_MODE, which is why ZJIT CI (--enable-zjit=dev) does
not catch these.