Implement support in the component model for memory64

[alexcrichton]

I'm going to split this work item from #4185 since I suspect it's going to be somewhat significant. The intention here is to track issues related to the memory64 proposal for WebAssembly and the component model. At the time of this writing neither of these proposals are "stable". Additionally the component model does not actually define what the canonical ABI is with respect to the memory64 proposal. Fully implementing this item will be a blend of "do the obvious thing" where possible such as making pointers 64-bits large, while at the same time also identifying question that don't have "obvious" answers such as "what's the maximum length of a string or list?"

Currently there are a lot of TODO items sprinkled throughout typed.rs which note various places that I suspect will need memory64 treatment. Fully implementing this issue, however, will likely require fuzzer integration because otherwise it'll be difficult to ensure that we've covered all cases.

Some examples of things that need updating are:

• Need to call realloc with a different signature
• All reads/writes of pointers to linear memory need to have a 32/64 bit switch
• Reading and writing pointers to ValRaw needs to be audited
• Size and alignment calculations all need to be duplicated or have a parameter for 64 bit
• Somehow should probably confirm that this doesn't vastly affect performance for 32-bit

The last point here is an open question I don't know how best to answer.

[alexcrichton]

The upstream issue for the component model repository and the spec defining what to do with the memory64 proposal is WebAssembly/component-model#22