Add a references section with useful links

Add template for suggesting new instructions.

* Add paragraph on fpenv

* Attribute must be 0 for now, call it a module element

* Name fpu to make examples clearer

* Reword paragraph on fpenv instantiation

* Reword last paragraph describing what fpenv is

* Add attribute 0 to import example

As this is the first time we have separate proposals under the same subgroup - I'm duplicating the charter here as well as in the flexible vectors proposal for discoverability, and for easy modification in case we decide to split the subgroup based on proposals in the future.

#22

For #21.

See #27.

For #33.

As suggested in
WebAssembly/relaxed-simd#17 (comment).

Merge upstream

Report status of SpiderMonkey implemention

Remove fpenv from overview, add proposed spec text on Relaxed operations

Merge upstream

"either" allows us to assert that the a value is in a set of expected
values. This is copied from threads proposal and updated accordingly
to compile.

Test cases are not exhaustive and only exercises edge cases (where
results differ across hardware). No implementation in the interpreter,
only parsing, encoding, and decoding is supported.

Merge upstream

Merge upstream

Merge upstream

…add)

For #27.

Merge upstream

For #94.

Merge upstream

For #117

Remove bf16 dot

For #117

Fix names of dot instructions

Fix expected result type in relaxed dot product tests

Fixes #110

Check multiple calls to relaxed instructions return same results

Add expected results for relaxed dot

nmadd(x, y, z) == nmadd(-x, y, z)

the tests were doing -z instead.

Fixes #126.

Merge from upstream spec

This fixes some minor issues I encountered when running these tests. The
first is a test for the `i32x4.relaxed_trunc_f32x4_s` instruction which
asserted that `2147483647.0` (INT_MAX) would get translated to INT_MAX
through the conversion. This float value, however, is not representable
in `f32`. The two other closest integers that `f32` can represent are
2147483648 and 2147483520, so it's not actually possible to exercise a
conversion from precisely INT_MAX to INT_MAX. Due to float parsing this
meant that the value was getting rounded up to 2147483648 which exceeded
INT_MAX which when using `cvttpd2dq` on x86 would cause INT_MIN to get
returning, failing the test. I updated the test to pass something
in-bounds (2 in this case) since the other edge cases are already
tested.

The other issue fixed in this commit is that many tests asserted that
INT_MIN was a possible result but the representation of INT_MIN was
missing a 0 in its hexadecimal representation, so zeros were appended.

relaxed swizzle -> swizzle
relaxed trunc -> trunc sat
madd/nmadd -> fused multiply add/sub (2 roundings)
relaxed laneselect -> bitselect
relaxed min/max -> min/max
i16x8 q15mulr -> i16x8.q15mulr with sat

Co-authored-by: Andreas Rossberg <[email protected]>

Currently the overview indicates that if the mask lane is not zero,
not all-ones, and the top bit is 0 then the output must be the `b`
element.  This doesn't match (what I believe is) the intended
implementation on AArch64 using the `bsl` instruction which is the same
as `v128.bitselect`.