Allows to remove some duplicated code like szqueue_length, etc.

[Bug #21771]

It may raise so it's incorrect and can lead to the compiler
optimizing the call out.

`T_DATA` has a flag `RUBY_TYPED_FROZEN_SHAREABLE` which means
if the `T_DATA` object is frozen, it can be sharable.
On the `Ractor.make_sharable(obj)`, rechable objects from the
`T_DATA` object will be apply `Ractor.make_shareable` recursively.

`RUBY_TYPED_FROZEN_SHAREABLE_NO_REC` is similar to the
`RUBY_TYPED_FROZEN_SHAREABLE`, but doesn't apply `Ractor.make_sharable`
recursively for children.
If it refers to unshareable objects, it will simply raise an error.

I'm not sure this pattern is common or not, so it is not in public.
If we find more cases, we can discuss publication.

While profiling `Monitor#synchronize` and `Mutex#synchronize`
I noticed a fairly significant amount of time spent in
`rb_check_typeddata`.

By implementing a fast path that assumes the object is valid
and that can be inlined, it does make a significant difference:

Before:

```
  Mutex     13.548M (± 3.6%) i/s   (73.81 ns/i) -     68.566M in   5.067444
Monitor     10.497M (± 6.5%) i/s   (95.27 ns/i) -     52.529M in   5.032698s
```

After:

```
  Mutex     20.887M (± 0.3%) i/s   (47.88 ns/i) -    106.021M in   5.075989s
Monitor     16.245M (±13.3%) i/s   (61.56 ns/i) -     80.705M in   5.099680s
```

```ruby
require 'bundler/inline'

gemfile do
  gem "benchmark-ips"
end

mutex = Mutex.new
require "monitor"
monitor = Monitor.new

Benchmark.ips do |x|
  x.report("Mutex") { mutex.synchronize { } }
  x.report("Monitor") { monitor.synchronize { } }
end
```

Instead of the offset calculation.

`IS_TYPED_DATA` is no longer a flag in `type`, and the "embedded" flag
has been shifted accordingly.

ruby/ruby#14470