Simd values in WASM - JS inteface

[arunetm-zz]

SIMD values may appear in WASM-JS interface at the function interfaces and as globals. Without SIMD.js its not clear how these be represented in JS.

Should the calls in/out of JS with simd arg/ret throw immediately like its done for i64 WebAssembly/design#923? A similar situation arises for imported globals as well.

1. For module imports
   If the signature contains an simd value (as argument or result), the host function immediately throws a TypeError when called.

2. For global imports
   If the global_type of the import is a simd value, throw a WebAssembly.LinkError

3. For exported globals
   If global is a simd value, throw a WebAssembly.LinkError.

4. WebAssembly Exported Functions have a [[Call]](this, argValues) method defined as:
   Let sig be the function type of the function's [[Closure]].
   If sig contains an simd value (as argument or result), a TypeError is thrown.

[Cellule]

A few concerns:

1. Why isn't accepted to have simd types in imported functions ? It's just another Wasm function that was exported and it should be fine to use. Like we do for int64
2. Today we throw a TypeError when we try to export int64, I think we should keep it the same for simd
3. Same as 2.
4. Same as 1. we should allow to export functions with simd type, what should be disallowed is calling such functions from javascript as-in when we try to convert a var to simd for args or simd to var for return we throw. Just like we do for int64.

In general, we shouldn't make simd a special case, we already have int64 as a example of a type that doesn't exist in javascript, simd should behave the same way.
Also note that with the Mutable-Global proposal we should allow simd types to be exported in the WebAssembly.Global object

[arunetm]

@Cellule I agree with the new recommendations. The earlier proposal was intended not to have SIMD as a special case and it was supposed to match with the handling of int64, unless there is a good reason not to. I think they diverged as int64 proposal evolved. Thanks for pointing this out.

[arunetm]

Fixed here: #44