Found via `grep` for repeated words.

* set.c: Fix "or or"
* include/ruby/internal/symbol.h: Fix "is is"
* include/ruby/internal/ctype.h: Fix "in in"

* test(set): add test Set#xor does not mutate other_set

* Fix Set#^ to not mutate its argument

For subclasses from Set, require `set/subclass_compatible`, and
extend the subclass and include a module in it that makes it more
backwards compatible with the pure Ruby Set implementation used
before Ruby 4.

The module included in the subclass contains a near-copy of the
previous Set implementation, with the following changes:

* Accesses to `@hash` are generally replaced with `super` calls. In
  some cases, they are replaced with a call to another instance method.
* Some methods that only accessed `@hash` and nothing else are not
  defined, so they inherit behavior from core Set.
* The previous `Set#divide` implementation is not used, to avoid
  depending on tsort.

This fixes the following two issues:

* [Bug #21375] Set[] does not call #initialize
* [Bug #21396] Set#initialize should call Set#add on items passed in

It should also fix the vast majority of backwards compatibility issues
in other cases where code subclassed Set and depended on implementation
details (such as which methods call which other methods).

This does not affect Set internals, so Set itself remains fast. For
users who want to subclass Set but do not need to worry about
backwards compatibility, they can subclass from Set::CoreSet, a Set
subclass that does not have the backward compatibility layer included.

This reverts commit d4020dd5faf28486123853e7f00c36139fc07793, which introduced performance regression for objects like ActiveRecord::Relation by calling the costly #size method on them.

This saves one pointer in `struct set_table`, which would allow
`Set` objects to still fit in 80B TypedData slots even if RTypedData
goes from 32B to 40B large.

The existing set benchmark seem to show this doesn't have a very
significant impact. Smaller sets are a bit faster, larger sets
a bit slower.

It seem consistent over multiple runs, but it's unclear how much
of that is just error margin.

```
compare-ruby: ruby 3.5.0dev (2025-08-12T02:14:57Z master 428937a536) +YJIT +PRISM [arm64-darwin24]
built-ruby: ruby 3.5.0dev (2025-08-12T07:22:26Z set-entries-bounds da30024fdc) +YJIT +PRISM [arm64-darwin24]
warming up........

|                         |compare-ruby|built-ruby|
|:------------------------|-----------:|---------:|
|new_0                    |     15.459M|   15.823M|
|                         |           -|     1.02x|
|new_10                   |      3.484M|    3.574M|
|                         |           -|     1.03x|
|new_100                  |    546.992k|  564.679k|
|                         |           -|     1.03x|
|new_1000                 |     49.391k|   48.169k|
|                         |       1.03x|         -|
|aref_0                   |     18.643M|   19.350M|
|                         |           -|     1.04x|
|aref_10                  |      5.941M|    6.006M|
|                         |           -|     1.01x|
|aref_100                 |    822.197k|  814.219k|
|                         |       1.01x|         -|
|aref_1000                |     83.230k|   79.411k|
|                         |       1.05x|         -|
```

The `p->field = rb_gc_location(p->field)` isn't ideal because it means all
references are rewritten on compaction, regardless of whether the referenced
object has moved. This isn't good for caches nor for Copy-on-Write.

`rb_gc_mark_and_move` avoid needless writes, and most of the time allow to
have a single function for both marking and updating references.