Improve JITability of Calc-related code:

[vaisest]

Description of the problem being solved:

This improves raw calc performance by around 25% (measured with repeatedly running power reports on a sample build using a LuaJIT script) by reducing the amount of interpreted code. The changes so far include:

• Convert ModStore code to not use select(i, ...) and to not pass ... onwards. This is done by unpacking n1 through n8 if there are multiple arguments.
• Move some closure definitions out of functions as this breaks traces.
• Convert AND64 and others to not do {...}, which results in a table allocation for each call (not in all cases, but in this case it does). This is done in a similar way to the ModStore changes.

It might be possible to avoid the last change and to use local args = {...} alongside select(#, ...) (but apparently not #args, idk). There's some really confusing/complex stuff going on with "allocation sinking" or something. It's certain that in interpreted mode it always allocates, but supposedly there is no allocation when the table doesn't leave the trace/function. The problem here is mostly uncertainty since for some reason there are no up to date docs on how to avoid breaking the JIT.

This should also allow for further optimisations, since as far as I know, breaking traces can mean blacklisting whole loops which prevents other code from being compiled.

The first commit changes here are mostly from an LLM, with additional code style changes done afterwards. This is mostly because these are just tedious changes and duplicated code, which can't be avoided due to the way the functions are used.

Steps taken to verify a working solution:

• Tests pass (the failing test here is me disabling the class footgun so it doesn't interfere with performance)
• Nothing exploded
• Call sites themselves were not changed, and so it is unlikely that anything has broken here.

Link to a build that showcases this PR:

Not really relevant, but this is what I tested with: https://poe.ninja/poe2/pob/27bcb

[vaisest]

This PR now results in around a 35% synthetic power report performance increase, and brings the share of interpreted VM time from 41% to 15%. The tested build was the linked twister build (despite it being called ICESHOT.xml).

I think this idea suffers a bit from the code style in this project. For some reason, extremely large functions are preferred, and as far as I'm aware, having one closure in a function means that the function will never be compiled. Separating functionality to smaller functions could have a performance impact, along with making changes easier as side effects are clearer.

The base commit a92b33d:

=== Power report benchmark ===
Build:        Builds/ICESHOT.xml
Power stat:   Offence/Defence
Report rows:  0
Warmup/iters: 2 / 12
-------------------------------
min:    2449.32 ms
median: 2752.82 ms
mean:   2766.65 ms
max:    3002.22 ms
===============================
41%  Interpreted
36%  Compiled
18%  Garbage Collector
 3%  C code

Commit 47d8f88 (clanker changes):

=== Power report benchmark ===
Build:        Builds/ICESHOT.xml
Power stat:   Offence/Defence
Report rows:  0
Warmup/iters: 2 / 12
-------------------------------
min:    2038.08 ms
median: 2195.56 ms
mean:   2248.67 ms
max:    2574.23 ms
===============================
55%  Compiled
20%  Interpreted
17%  Garbage Collector
 5%  JIT Compiler
 3%  C code

Commit b2c4d5c (my changes along with maxtrace=20000):

=== Power report benchmark ===
Build:        Builds/ICESHOT.xml
Power stat:   Offence/Defence
Report rows:  0
Warmup/iters: 2 / 12
-------------------------------
min:    1983.86 ms
median: 2003.60 ms
mean:   2070.46 ms
max:    2285.04 ms
===============================
65%  Compiled
16%  Garbage Collector
15%  Interpreted
 3%  C code