Interaction with the memory64 proposal

With the memory64 proposal for WebAssembly this will change the internal representation of types in the canonical ABI, notably where strings/lists now have 64-bit pointers and lengths instead of 32-bit pointers/lengths as they would today. The canonical ABI isn't fully fleshed out on the main branch yet but I wanted to open this issue ahead of time to start the discussion and log it at least.

In my mind the memory64 proposal provides a great opportunity to showcase how definitions of APIs at the component model layer works well regardless of the underlying wasm module. For example today WASI isn't specified for memory64 and might take a significant amount of work for both engines and toolchains alike to all catch up and define something for memory64. That being said if WASI were defined with the component model then defining the canonical ABI lowering from interface types to memory64 memories would be all that's necessary and bindings generators/engines would be updated appropriately to pick up support quickly.

In any case this is also somewhat of a pretty future-facing feature because of the relatively early stages of not only the memory64 proposal but also adoption in general. I figured it might be useful to keep in the back of our heads when defining the canonical abi though (e.g. the size of a type now needs to be parameterized on the size of memory in addition to the type itself)

Start with the linked memory64 proposal and the canonical ABI work on the main branch; compare how pointer and length widths, plus type sizes, should vary with memory size. The issue names no files or tests, so done would require a settled design for memory64 canonical ABI lowering and documented implications for WASI and bindings.