Cranelift: update regalloc2 to 0.15.0 to permit more VRegs.

[cfallin]

This pulls in bytecodealliance/regalloc2#257 to permit more VRegs to be used in a single function body, addressing #12229 and our followup discussions about supporting function body sizes up to the Wasm implementation limit standard.

In addition to the RA2 upgrade, this also includes a bit more explicit limit-checking on the Cranelift side: note that we don't directly use regalloc2::VReg but instead we further bitpack it into Reg, which is logically a sum type of VReg, PReg and SpillSlot (the last one needed to represent stack allocation locations on defs, e.g. on callsites with many returns). PRegs are packed into the beginning of the VReg index space but SpillSlots are distinguished by stealing the upper bit of a u32. This was previously not a problem given the smaller VReg index space but now we need to check explicitly; hence Reg::from_virtual_reg_checked and its use in the lowering vreg allocator. Because the VReg index packs the class into the bottom two bits, and index into the upper 30, but we steal one bit at the top, the true limit for VReg count is thus actually 2^29, or 512M.

Fixes #12229.

[cfallin]

The failing test (code_too_large) fails as expected because we now support the generated function body size. A few thoughts though:

• In theory it should be impossible to write this test once we fully hit the goal of "compile any valid Wasm function that wasmparser's implementation-limit checks pass on";
• But there's still the interesting question of whether there's a "gap" as we sweep the code size upward where we start to throw errors;
• In attempting to check this by increasing the test's N, I found that our ValueDataPacked encoding gives 24 bits to value numbers, so I'm working on reclaiming some bits there. In particular the Type encoding seems pretty inefficient so I'll try to steal some of those bits back.

[alexcrichton]

I think that test already takes forever to compile/run in debug mode on all platforms so jettisoning that test doesn't seem unreasonable to me, and agreed it in theory should not be possible to write. Maybe it's sufficient to have a local script to run or some online corpus of "must compile big modules" or something like that?

Either that or we could create a dedicated test job for "compile wasmtime in release on one fast platform and compile big modules" to make sure everything succeeds.

[cfallin]

Sure thing -- I'll push the "corpus of big inputs to test" as followup (after #12613 lands as well); removed the code_too_large test here.