[Bug #21357] Fix crash in Hash#merge with block

	Prior to https://github.com/ruby/ruby/commit/49b306ecb9e2e9e06e0b1590bacc5f4b38169c3c
	the `optional_arg` passed from `rb_hash_update_block_i` to `tbl_update`
	was a hash value (i.e. a VALUE). After that commit it changed to an
	`update_call_args`.

	If the block sets or changes the value, `tbl_update_modify` will set the
	`arg.value` back to an actual value and we won't crash. But in the case
	where the block returns the original value we end up calling
	`RB_OBJ_WRITTEN` with the `update_call_args` which is not expected and
	may crash.

	`arg.value` appears to only be used to pass to `RB_OBJ_WRITTEN` (others
	who need the `update_call_args` get it from `arg.arg`), so I don't think
	it needs to be set to anything upfront. And `tbl_update_modify` will set
	the `arg.value` in the cases we need the write barrier.

	[Bug #21333] Prohibit hash modification inside Hash#update block

	[Bug #21331] Prohibit hash modification during stlike loop

[Bug #21170]

st_table reserves -1 as a special hash value to indicate that an entry
has been deleted. So that that's a valid value to be returned from the
hash function, do_hash replaces -1 with 0 so that it is not mistaken for
the sentinel.

Previously, when upgrading an AR table to an ST table,
rb_st_add_direct_with_hash was used which did not perform the same
conversion, this could lead to a hash in a broken state where one if its
entries which was supposed to exist being marked as a tombstone.

The hash could then become further corrupted when the ST table required
resizing as the falsely tombstoned entry would be skipped but it would
be counted in num entries, leading to an uninitialized entry at index
15.

In most cases this will be really rare, unless using a very poorly
implemented custom hash function.

This also adds two debug assertions, one that st_add_direct_with_hash
does not receive the reserved hash value, and a second in
rebuild_table_with, which ensures that after we rebuild/compact a table
it contains the expected number of elements.

Co-authored-by: Alan Wu <alanwu@ruby-lang.org>

	[Bug #20307] Fix `Hash#update` to make frozen copy of string keys

	Memory leak when duplicating identhash

	[Bug #20145]

	Before this commit, both copy_compare_by_id and hash_copy will create a
	copy of the ST table, so the ST table created in copy_compare_by_id will
	be leaked.

	    h = { 1 => 2 }.compare_by_identity

	    10.times do
	      1_000_000.times do
	        h.select { false }
	      end

	      puts `ps -o rss= -p #{$$}`
	    end

	Before:

	    110736
	    204352
	    300272
	    395520
	    460704
	    476736
	    542000
	    604704
	    682624
	    770528

	After:

	    15504
	    16048
	    16144
	    16256
	    16320
	    16320
	    16752
	    16752
	    16752
	    16752
	---
	 hash.c                 | 10 +++++++++-
	 test/ruby/test_hash.rb | 10 ++++++++++
	 2 files changed, 19 insertions(+), 1 deletion(-)

proposed at https://bugs.ruby-lang.org/issues/20050#note-5

We didn't free the old ST before overwriting it which caused a leak.
Found with RUBY_FREE_ON_EXIT.

Co-authored-by: Peter Zhu <peter@peterzhu.ca>