When these instructions were introduced it was common to read from a
hash with mutable string literals.  However, these days, I think these
instructions are fairly rare.

I tested this with the lobsters benchmark, and saw no difference in
speed.  In order to be sure, I tracked down every use of this
instruction in the lobsters benchmark, and there were only 4 places
where it was used.

Additionally, this patch fixes a case where "chilled strings" should
emit a warning but they don't.

```ruby
class Foo
  def self.[](x)= x.gsub!(/hello/, "hi")
end

Foo["hello world"]
```

Removing these instructions shows this warning:

```
> ./miniruby -vw test.rb
ruby 3.5.0dev (2025-08-25T21:36:50Z rm-opt_aref_with dca08e286c) +PRISM [arm64-darwin24]
test.rb:2: warning: literal string will be frozen in the future (run with --debug-frozen-string-literal for more information)
```

[Feature #21553]

When using MN threads (such as running the test in a ractor), this test
failed because it was raising a SystemStackError: stack level too deep.

This is because the machine stack is smaller under MN threads than on
the native main thread.

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.

This reverts commit bb180b87b43c45e17ff49735a26d7a188d5c8396, which
caused "malloc during GC" error on wasm.

The code between the two ObjectSpace.count_objects could trigger a GC,
which could free string objects causing this test to fail.

We can see this failure on CI http://ci.rvm.jp/results/trunk-random2@ruby-sp2-noble-docker/5651016

    TestHashOnly#test_AREF_fstring_key [test/ruby/test_hash.rb:1991]:
    <197483> expected but was
    <129689>.

[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>