Add support for (either ...) in wast

[stevenfontanella]

• Adds support for (either ...) in assert_return in WAST
• Also allows customizing the error type in Result, which we use to keep track of the failing lane in assertions.

Example failure:

(module
  (func (export "f") (result i32)
    (i32.const 1)
  )
)

(assert_return (invoke "f") (either (i32.const 2) (i32.const 3)))

Expected one of (2 | 3) but got 1

Example failure with SIMD from relaxed_min_max.wast:

Expected one of (canonical f32 | canonical f32 | 0 | 0x00000000) at lane 0 but got i32x4 0x7fc00000 0x7fc00000 0x7fc00000 0x7fc00000

Part of #8261 and #8315. Fixes i16x8_relaxed_q15mulr_s.wast, i8x16_relaxed_swizzle.wast, relaxed_madd_nmadd.wast spec tests, and partially fixes relaxed_dot_product.wast, relaxed_laneselect.wast, relaxed_min_max.wast, and threads/thread.wast.

[tlively]

Why is this better or more correct?

[stevenfontanella]

I based this off of Google's style guide for absl::StatusOr which recommends moving from the whole thing instead of just the value inside to indicate that the whole result type is moved-from. Basically it would likely be a mistake to do something with r after this and moving r instead of *r hints that to the reader. I got it from here (ctrl+f "Moving from the value"): https://abseil.io/tips/181

[tlively]

Interesting! Makes sense, though I find it slightly less intuitive. Seems fine to introduce here.

[tlively]

We should probably check that the value is not null here, too.

[tlively]

Can we avoid hard-coding a lane interpretation here? Maybe we should always use LaneResults for vectors if we want to be more precise about lanes in error messages?

[tlively]

It's not clear to me why we check isAlternative here.

[tlively]

Do you know whether either cases are supposed to handle multiple values in the case of multivalue or whether each value gets its own either clause? I would have expected the former, in which case this loop would have to be inside the either handling. (But if there are no tests that exercise this yet, it's ok to leave a TODO rather than fixing it.)

[stevenfontanella]

According to the spec it's the latter:

So we can say

(assert_return (invoke "foo") (either a b) (either c d))

But not

(assert_return (invoke "foo") (either (a c) (b d))

[tlively]

Interesting, thanks.