Cranelift: alias analysis: track each individual table/heap separately

In #4163 we are introducing an alias analysis and redundant-load elimination / store-to-load-forwarding transform.

This initial implementation categorizes all memory accesses as one of four kinds: to a "heap", to a "table", to the "vmctx", or to everything else. These four categories are allowed to be optimized separately from each other; so e.g. a store to a table does not prevent a load from a heap from being merged with an earlier load, if otherwise to the same address.

This is correct, and simple, and allows us to keep just four bits in `MemFlags` and four `u32`s for the "last store" vector, per instruction. However, it is somewhat more imprecise than we would like, especially in the future when we expect multiple modules, memories, tables, etc. to become more common.

Thus, we should investigate ways of efficiently representing an arbitrary number of heaps or tables as separate categories of abstract state. This may require an extended `MemFlag`s, or indirection of some kind, or some limit (first 16, 32, ... memories are privileged).