[WebAssembly] Fall back to SelectionDAG for vector compares in FastISel (#227368)

FastISel's selectICmp and selectFCmp each classify compare operands
with a single scalar test: anything but i64 is treated as i32, and
anything but f64 as f32, vectors included. A vector compare therefore
emits a scalar i32.eq/i32.ne (or f32.eq) that consumes the two v128
registers holding the operands, and the resulting module fails
validation ("type mismatch: expected i32, found v128").

Return false for vector operands in both selectors so the SelectionDAG
lowers them to SIMD compares, and extend the existing
fast-isel-simd128.ll test to cover vector compares on both wasm32 and
wasm64 (UTC-generated checks, with the vectors passed in as arguments).

The vector compare only reaches this path when the rest of the block
does not bail out, which is why it went unnoticed: the common shapes
(a vector icmp feeding extractelement, a bitcast, an intrinsic, or a
branch condition) all miss somewhere in FastISel and the SelectionDAG
revisits the block, replacing the bad compare. A vector compare
feeding an ordinary call is the shape that survives, because FastISel
lowers calls fine and nothing misses.

Found compiling wasm64 programs, where vector compares stay live
through call boundaries; the module was rejected by wasmtime.