[Bug #21775]

with `RUBY_TYPED_FROZEN_SHAREABLE_NO_REC`,
if the receiver object is shareable on Method objects.

assert_ractor() runs in a subprocess.

Fixes a segmentation fault when moving nested objects between ractors with GC stress enabled and YJIT.

The issue is a timing problem: `move_enter` allocates new object shells but leaves their contents uninitialized until `move_leave` copies the actual data. If GC runs between these steps (which GC stress makes likely), it tries to follow what appear to be object pointers but are actually uninitialized memory, encountering null or invalid addresses.

The fix zero-initializes the object contents immediately after allocation in `move_enter`, ensuring the GC finds safe null pointers instead of garbage data.

The crash reproduced most consistently with nested hashes and YJIT, likely because nested structures create multiple uninitialized objects simultaneously while YJIT's memory usage increases the probability of GC triggering during moves.

call-seq:
  Ractor.sharable_proc(self: nil){} -> sharable proc

It returns shareable Proc object. The Proc object is
shareable and the self in a block will be replaced with
the value passed via `self:` keyword.

In a shareable Proc, the outer variables should
* (1) refer shareable objects
* (2) be not be overwritten

```ruby
  a = 42
  Ractor.shareable_proc{ p a }
  #=> OK

  b = 43
  Ractor.shareable_proc{ p b; b = 44 }
  #=> Ractor::IsolationError because 'b' is reassigned in the block.

  c = 44
  Ractor.shareable_proc{ p c }
  #=> Ractor::IsolationError because 'c' will be reassigned outside of the block.
  c = 45

  d = 45
  d = 46 if cond
  Ractor.shareable_proc{ p d }
  #=> Ractor::IsolationError because 'd' was reassigned outside of the block.
```

The last `d`'s case can be relaxed in a future version.

The above check will be done in a static analysis at compile time,
so the reflection feature such as `Binding#local_varaible_set`
can not be detected.

```ruby
  e = 42
  shpr = Ractor.shareable_proc{ p e } #=> OK
  binding.local_variable_set(:e, 43)
  shpr.call #=> 42 (returns captured timing value)
```

Ractor.sharaeble_lambda is also introduced.
[Feature #21550]
[Feature #21557]

MinGW is also Windows, so it doesn't work for MinGW either.
https://github.com/ruby/ruby/actions/runs/17250269899/job/48950567246

[Bug #20146]

Previously we dealt with the main Ractor not being enabled for M:N by
incrementing snt_cnt++. This worked for comparing against ractor count,
but meant that we always had one less SNT than was specified by
RUBY_MAX_CPU.

This was notably a problem for RUBY_MAX_CPU=1, which would cause Ractors
to hang.

This commit instead of adjusting snt, adjusts a
"schedulable_ractor_cnt". This way snt_cnt will actually reach
RUBY_MAX_CPU.

https://github.com/ruby/ruby/actions/runs/16995599804/job/48185434078?pr=14242

https://github.com/ruby/ruby/actions/runs/16977882022/job/48131284556

https://github.com/ruby/ruby/actions/runs/16977094733/job/48128667252?pr=14229