Where should the memory model spec live?

Three options:

• Wasm spec references JS spec for the memory model. This is the easiest model to start with. If Wasm needs to express something that's not available in JS, it can explain that in terms of a patch to the JS memory model. We can refactor the JS memory model to make it more amenable to use by Wasm, if it makes sense.
• Separate JS and Wasm memory models. This avoids the Wasm spec normatively referencing the JS spec, wihch @rossberg-chromium considered a goal. However, considering that they may be operating on the same block of memory, it could become a bit difficult to understand what guarantees there are when the worlds interact.
• Wasm spec and JS spec both reference an underlying separate memory model spec. Possibly best of both worlds? There are just some organizational boundaries. We also may have some iteration on the format, if some feel that the JS memory model isn't using the right kind of notation/formalism (could be a pro or con).

Any thoughts on these options?

(thread split off from https://github.com/WebAssembly/threads/issues/9)

Start by reviewing the three proposed placements for the memory model and the discussion split from issue 9. Done means reaching and recording a decision about whether the model belongs in the Wasm spec, the JS spec, or a separate shared specification.