compile_data_calloc2 may run GC (though because it allocates from an
arena this is rare in practice). When this happened when resizing
operands there was a risk of seeing the insn in an inconsistent state.

To solve this we need to make any allocations before we start modifying
the instrucitons. This refactors the code to use a new
insn_replace_with_operands() function that allocates the new operands
array before modifying the instruction object.

Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

Previously, ZJIT miscompiled the following because of native SP
interference.

    def a(n1,n2,n3,n4,n5,n6,n7,n8) = [n8]
    a(0,0,0,0,0,0,0, :ok)

Commented problematic disassembly:

    ; call rb_ary_new_capa
    mov x0, #1
    mov x16, #0x1278
    movk x16, #0x4bc, lsl #16
    movk x16, #1, lsl #32
    blr x16
    ; call rb_ary_push
    mov x1, x0
    str x1, [sp, #-0x10]! ; c_push() from alloc_regs()
    mov x0, x1            ; arg0, the array
    ldur x1, [sp]         ; meant to be arg1=n8, but sp just moved!
    mov x16, #0x3968
    movk x16, #0x4bc, lsl #16
    movk x16, #1, lsl #32
    blr x16

Since the frame pointer stays constant in the body of the function,
static offsets based on it don't run the risk of being invalidated by SP
movements.

Pass the registers to preserve through Insn::FrameSetup. This allows ARM
to use STP and waste no gaps between EC, SP, and CFP.

x86 now preserves and restores RBP since we use it as the frame pointer.
Since all arches now have a frame pointer, remove offset based SP
movement in the epilogue and restore registers using the frame pointer.

This implements similar fast-path guard type checks as YJIT.

While Integer can technically be subclassed, instances of subclasses
cannot be created. Remove it from the type lattice.

They can be subclassed but new instances cannot be created.

Adds a link to the GitHub Releases page for this gem consistent with other gems in the Ruby organization. Existing examples include:

- [json](https://github.com/ruby/json/blob/master/json.gemspec)
- [ostruct](https://github.com/ruby/ostruct/blob/master/ostruct.gemspec)

ruby/tsort@8086bb33bc

hash.c compiles just fine on HASH_DEBUG without including internal/gc.h.

ruby/json@9e3efbfa22

Visual C:
```
compiling ../../../../../src/ext/-test-/namespace/yay1/yay1.c
yay1.c
../../../../../src/ext/-test-/namespace/yay1/yay1.c(4): warning C4273: 'yay_value': inconsistent dll linkage
C:\a\ruby\ruby\src\ext\-test-\namespace\yay1\yay1.h(4): note: see previous definition of 'yay_value'
linking shared-object -test-/namespace/yay1.so
   Creating library yay1-arm64-mswin64_140.lib and object yay1-arm64-mswin64_140.exp
yay1-arm64-mswin64_140.exp : warning LNK4070: /OUT:yay1.dll directive in .EXP differs from output filename '..\..\..\..\.ext\arm64-mswin64_140\-test-\namespace\yay1.so'; ignoring directive
compiling ../../../../../src/ext/-test-/namespace/yay2/yay2.c
yay2.c
../../../../../src/ext/-test-/namespace/yay2/yay2.c(4): warning C4273: 'yay_value': inconsistent dll linkage
C:\a\ruby\ruby\src\ext\-test-\namespace\yay2\yay2.h(4): note: see previous definition of 'yay_value'
linking shared-object -test-/namespace/yay2.so
   Creating library yay2-arm64-mswin64_140.lib and object yay2-arm64-mswin64_140.exp
yay2-arm64-mswin64_140.exp : warning LNK4070: /OUT:yay2.dll directive in .EXP differs from output filename '..\..\..\..\.ext\arm64-mswin64_140\-test-\namespace\yay2.so'; ignoring directive
```

From MinGW gcc:
```
../../../../../src/ext/-test-/namespace/yay1/yay1.c:4:1: warning: 'yay_value' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
    4 | yay_value(void)
      | ^~~~~~~~~
../../../../../src/ext/-test-/namespace/yay2/yay2.c:4:1: warning: 'yay_value' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
    4 | yay_value(void)
      | ^~~~~~~~~
```

ref: https://bugs.ruby-lang.org/issues/21513

Before this patch, trying to convert endless range (e.g. `(1..)`) to set
(using `to_set`) would hang

It has been marked as obsolete for a while and I see no reason
to keep it.

Since `RUBY_DESCRIPTION` contains the branch name, `/prism/i` can
match unexpectedly.  Extract the feature lists between revision
and platform infos.