Resize ary when `Array#sort!` block modifies embedded ary

	In cases where `rb_ary_sort_bang` is called with a block and
	tmp is an embedded array, we need to account for the block
	potentially impacting the capacity of ary.

	ex:
	```
	var_0 = (1..70).to_a
	var_0.sort! do |var_0_block_129, var_1_block_129|
	  var_0.pop
	  var_1_block_129 <=> var_0_block_129
	end.shift(3)
	```

	The above example can put the array into a corrupted state
	resulting in a heap buffer overflow and possible segfault:
	```
	ERROR: AddressSanitizer: heap-buffer-overflow on address [...]
	WRITE of size 560 at 0x60b0000034f0 thread T0 [...]
	```

	This commit adds a conditional to determine when the capacity
	of ary has been modified by the provided block. If this is
	the case, ensure that the capacity of ary is adjusted to
	handle at minimum the len of tmp.

ary could change embeddedness due to compaction, so we should only get
the pointer after allocations.

The included test was crashing with:

    TestArray#test_slice_gc_compact_stress
    ruby/lib/pp.rb:192: [BUG] Segmentation fault at 0x0000000000000038

The ary_make_shared call may allocate, which can trigger a GC
compaction. This can cause the array to be embedded because it has a
length of 0.

We can use an hidden Hash instead, it's simpler, triggers
write barriers, handle compaction, etc.

We don't need to remove the write-barrier protected status after
splicing an array. We can simply add it to the rememberset for marking
during the next GC.

The benchmark illustrates the performance impact on minor GC:

```
require "benchmark"

arys = 1_000_000.times.map do
  ary = Array.new(50)
  ary.insert(1, 3)
  ary
end

4.times { GC.start }

puts(Benchmark.measure do
  1000.times do
    GC.start(full_mark: false)
  end
end)
```

This branch:

```
  1.309910   0.004342   1.314252 (  1.314580)
```

Master branch:

```
 54.376091   0.219037  54.595128 ( 54.742996)
```