Replace our LSL integer implementation with Luau's new 64-bit integers

[HaroldCindy]

May be a little tricky since They use 64-bit ints and we use 32-bit, but we don't actually have to use the integer library itself at all under LSL. Shouldn't be a heavy lift, though we'll have to retain our lvmexecute tricks to allow LOP_ADD and such with integer in LSL mode to not blow up the bytecode size.

Will probably want to wait until Luau's integer implementation has more time to bake so the API doesn't shift out from under us.

[tapple]

all the integer functions are fastcalls. how big are fastcalls vs operators?

$ cat pow.op.luau 
local _ = 5 ^ 6
$ ./luau-compile pow.op.luau -O0
Function 0 (??):
    1: local _ = 5 ^ 6
LOADK R1 K0 [5]
LOADK R2 K1 [6]
POW R0 R1 R2
    2: 
RETURN R0 0

$ ./luau-compile --binary pow.op.luau -O0 | wc -c
67

$ cat pow.func.luau 
local _ = math.pow(5, 6)
$ ./luau-compile pow.func.luau
Function 0 (??):
REMARK builtin math.pow/2
    1: local _ = math.pow(5, 6)
LOADN R1 5
FASTCALL2K 21 R1 K0 L0 [6]
LOADK R2 K0 [6]
GETIMPORT R0 3 [math.pow]
CALL R0 2 1
    2: 
L0: RETURN R0 0

$ ./luau-compile --binary pow.func.luau | wc -c
96

$ touch blank.luau
$ ./luau-compile blank.luau 
Function 0 (??):
    1: 
RETURN R0 0

$ ./luau-compile --binary blank.luau | wc -c
34

• each operator is 67 - 34 = 33 bytes
• each fastcall is 96 - 34 - 7 = 55 bytes (-7 for #"math" + #"pow")
• fastcall generate 66% bigger bytecode

[HaroldCindy]

Correct, the fastcalls are fine for when a small amount of your code is integer math. When your code is dominated by integer math (as is the case in typical LSL scripts) then using the opcode is preferable.