allocation_info_tracer_compact_update_object_table_i deletes entries where
the key is no longer in the GC heap but did not free the allocation_info
causing the memory to be leaked.

to prevent the following scenario:

1. `delete_unique_str()` can be called while GC (sweeping)
2. it calls `st_insert()` to decrement the counter
3. `st_insert()` can try to extend the table even if the key exists
4. `xmalloc` while GC and cause BUG

When reference updating ObjectSpace.trace_object_allocations, we need to
check whether the object is valid or not because it does not mark the
object so the object may be dead. This can cause a segmentation fault
if the object is on a free heap page.

For example, the following script crashes:

    require "objspace"

    objs = []
    ObjectSpace.trace_object_allocations do
      1_000_000.times do
        objs << Object.new
      end
    end

    objs = nil

    # Free pages that the objs were on
    GC.start

    # Run compaction and check that it doesn't crash
    GC.compact

We need to reinsert into the ST table when an object moves because it is
a numtable that hashes on the object address, so when an object moves we
need to reinsert it rather than just updating the key.

We should be checking for key for moved objects rather than the value
because the key is a Ruby object and the value is malloc'd memory.

[Feature #19425]

ObjectSpace.trace_object_allocations_start could crash since it adds a
TracePoint for when objects are freed. However, TracePoint could crash
since it modifies st tables while inside the GC that is trying to free
the object. This could cause a memory allocation to happen which would
crash if it triggers another GC.

See a crash log: http://ci.rvm.jp/results/trunk@ruby-sp1/4373707

[Misc #18891]

ObjectSpace.trace_object_allocations can crash when auto-compaction is
enabled.