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.

If string literals are long and they become shared, we need to make them
independent before we can write to them. [Bug #19116]

* Fix Array#[] with ArithmeticSequence with negative steps

Previously, Array#[] when called with an ArithmeticSequence
with a negative step did not handle all cases correctly,
especially cases involving infinite ranges, inverted ranges,
and/or exclusive ends.

Fixes [Bug #18247]

* Add Array#slice tests for ArithmeticSequence with negative step to test_array

Add tests of rb_arithmetic_sequence_beg_len_step C-API function.

* Fix ext/-test-/arith_seq/beg_len_step/depend

* Rename local variables

* Fix a variable name

Co-authored-by: Kenta Murata <3959+mrkn@users.noreply.github.com>

Previously it made object references without using write barriers,
creating GC inconsistencies.

See: http://ci.rvm.jp/results/trunk-gc-asserts@phosphorus-docker/3925529