(Luau-only) Many 32 bit tests fail due to 32 bit numbers using 64 bit APIs

[Hexcede]

Many 32 bit tests are only failing due to the usage of 64 bit libraries. For example, int_literals.wast.lua loads a constant 4294967295 and compares it with -1 in one of its tests, but this fails due to the usage of rt.eq.i64 in luau_assert.lua. There are several more complex cases like this.

[Hexcede]

This would require some kind of tracking of u32 vs u64. ffi takes care of this in luajit. Possibly instead of representing all u32s as u64s with upper zero bits, instead truncate the values so that u32s are represented as a table of 1 byte, whereas u64s are represented as a table of 2 bytes. This would allow for arbitrary length numbers as long as those lengths are byte-aligned (e.g. no 7 bit numbers or anything, not that those are going to show up in wasm).

[Hexcede]

Actually, alternatively it may be easier to just define __eq metamethods differently for u32 vs u64 but use the same structure. I do not believe the performance implications of this would be significant when using shared metatables and it would avoid having to rewrite APIs to support truncated values.

It could possibly even save performance (assuming proper 32 bit support) to use an __eq metamethod since we wouldn't need to add any code paths for truncated numbers. It sounds like the more appealing route to me either way.

P.s. this is effectively what the luajit case has with ffi since the ffi numbers are compared by ==.