`gc_prof_mark_timer_start` and `gc_prof_mark_timer_stop` include DTrace
hooks for the `MARK_BEGIN` and `MARK_END` events, respectively.
Previously, those probes are only triggered in `gc_marks`.  However,
`gc_marks_continue` and `gc_rest` also contain marking activities, but
are not captured by the probes.

We move the invocation of `gc_prof_mark_timer_start` and
`gc_prof_mark_timer_stop` into `gc_marking_enter` and `gc_marking_exit`
to ensure all marking activities are captured by the probes.

Snapshotting at start of marking lets sweep-time frees count against the
next epoch, which roughly halves GC frequency on alloc-heavy workloads.
Move the snapshot to end of sweep so the next epoch starts from a clean
baseline.

Several SETs in rb_gc_impl_stat may allocate a T_BIGNUM RVALUE when
the value exceeds FIXNUM_MAX

This is invisible on LP64 but trips on LLP64 Windows and ILP32 Linux
where FIXNUM_MAX ~= 1.07GB.

If those allocations happen *after* setting heap_live_slots then
stat[:heap_live_slots] reflects a stale snapshot, and tests that assert
on it fail.

This commit reorders everything so every potentially-allocating SET runs
first, and the slot counters are SET last.

Replace the single
objspace->malloc_counters.{increase,oldmalloc_increase} size_t fields
with pairs of monotonically-increasing counters. Snapshots of these
counters are taken at each GC, so that the live malloc_increase is computed as

    (malloc - malloc_at_last_gc) - (free - free_at_last_gc)

We update the baselines at each GC. Minor GC's update malloc and free
associated with young objects only (counters).

Major GC's update based on "oldcounters" as well.

The malloc/free counters are 64 bits wide which should provide ample
headroom for real world programs (>500 years at 1Gb/sec allocation rate
XD). We use size_t on 64-bit and uint64_t on 32-bit, wrapped by a
gc_counter_t struct.

However, because updating a uint64_t is a multi-instruction
operation on 32 bit architectures we have to introduce a lock to the
malloc_counters struct to avoid racing.

We introduced 2 new macros MALLOC_COUNTERS_LOCK and
MALLOC_COUNTERS_UNLOCK that use `rb_nativethread_lock_t`.

The lock is initialized in rb_gc_impl_objspace_init and destroyed in
rb_gc_impl_objspace_free. We chose this because it mirrors existing
finalizer_lock pattern in wbcheck.

On 64 bit platforms aligned 64 bit loads are atomic, and writes are
already using RUBY_ATOMIC_SIZE_ADD so the locks are not needed and the
macros do nothing.

We made a mistake calculating slot sizes during the heap slot sizes
refactor. Previously BASE_SLOT_SIZE included RVALUE_OVERHEAD, this was
lost during the refactor to use the SLOT macro.

The result of this was that when Ruby was compiled with -DRUBY_DEBUG it
was assumed that the last word of each slot was RVALUE_OVERHEAD. Because
this hadn't been taken into account at allocation time, all slots were
effectively one word shorter.

This PR adds RVALUE_OVERHEAD to the size calcualted in the SLOT macro
directly, so it will be added on to the physically allocated size at
allocation time.