[dart2wasm] Experiment with using tagged integers instead of boxing all integers

[mkustermann]

One difference compiling to JS vs WasmGC is that when we compile to WasmGC we currently always box integers when they flow in top types. This has the consequence that when one uses integers in lists, maps, json, etc we may have to allocate lots of objects (which is slow & memory hungry).

(We have added some workarounds here e.g. in the json decoder where we have a pre-allocated list of integer boxes for very small integers)

We could switch to using i31ref as top type. That would allow representing small integers without object allocations, matching what happens in dart2js. The consequence will be that certain operations will get slower (or larger in size): Loading class id from a top type has to check for i31 (this affects dispatches on selectors of Object such as toString() / hashCode ...), downcasts of receivers (possibly the same size, but slower in runtime as JS runtime will have to perform the integer/reference check), ...

See also related #52714 that would workaround this issue List<int> specifically via custom list implementations.

[mkustermann]

I've created a prototype of this. Some benchmarks improve but many regress. A major reason is that boxing and unboxing of integers becomes much more complicated than just allocating a struct and storing an i64 in it or loading it. That means that binaryen may not be able to turn unboxInt64(boxInt64(<value>)) into <value>.

We could experiment with adding a custom binaryen pass (similar to J2CL has custom passes) that optimizes boxing away. Alternative we could wait until we have an optimizing compiler in Dart that can do that.