create ifuncs for compiled blocks once at module load time

[froydnj]

Motivation

When a Ruby function rubyfunc receives a block implemented in C, a struct vm_ifunc is created for that block...on every call to rubyfunc. The compiler, of course, does this all the time, and it's suboptimal when compared to the interpreter: the interpreter does not require an extra allocation for passing an (interpreted) block to functions.

This PR intends to change that state of affairs by allocating the struct vm_ifunc up front at module load time. We can then re-use the structure on each call to rubyfunc, saving an allocation at runtime. I expect this to be beneficial for block-heavy benchmarks, but haven't yet gotten the chance to benchmark this.

Test plan

See included automated tests.

[froydnj]

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR. When the build
finishes, I'll share with you whether or how it failed. Thanks!

Stripe employees can see the build results here:

→ https://go/builds/bui_KeKHb3IPQ6znT1
→ https://go/builds/bui_KeKH1VpF6RB6mS

[aprocter-stripe]

I think this all seems reasonable! Just one cosmetic suggestion about something that would have made it easier to understand what was going on as I was reviewing.

If you're able, it would be neat to see some benchmarks before and after this change.

[aprocter-stripe]

I might suggest renaming to getOrBuildBlockIfunc. Working backwards from the call sites I found myself a bit confused that we were "building" an ifunc at certain places, but now I see that this actually uses getOrInsertGlobal.

[froydnj]

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR. When the build
finishes, I'll share with you whether or how it failed. Thanks!

Stripe employees can see the build results here:

→ https://go/builds/bui_KeN1EjP7xr7Cpa
→ https://go/builds/bui_KeN1DVOQAThRCf

[froydnj]

If you're able, it would be neat to see some benchmarks before and after this change.

It's not as effective as I hoped: it does indeed reduce the allocations to interpreter levels on the benchmark that motivated this, but the speedup is in the 1-5% range. Still probably worth it to avoid increasing memory pressure in compiled code?