[wasm2js] Support nontrapping float-to-int conversions directly in JS

[sbc100]

Now that 64-bit trunc_sat instructions are supported directly in I64ToI32Lowering (#9017), and 32-bit trunc_sat instructions are handled directly in wasm2js (~~expr and ~~expr >>> 0), we no longer need to run llvm-nontrapping-fptoint-lowering when --emscripten is passed.

In wasm2js, trapping float-to-int operations (i32.trunc_* and i64.trunc_*) are already lowered to non-trapping JS conversions (~~expr and float arithmetic in I64ToI32Lowering), which do not trap on out-of-range values or NaN/Infinity (matching C/C++ UB semantics rather than strict Wasm trapping semantics).

Removing llvm-nontrapping-fptoint-lowering extends that same direct approach to trunc_sat instructions under --emscripten, eliminating branching overhead and reducing code size.

Finally, add a commit to LLVMNontrappingFPToIntLowering.cpp about it have no known users after this change.

[sbc100]

I ran the whole wasm2js0, wasm2js1 and wasm2js2 test suites in emscripten with this change and (to my surprise) all tests passed.

[sbc100]

@kripken WDYT about these two stacked PRs combined? Do you think this approach is OK? I can't say I fully understand all the edge cases but the emscripten tests suite seems to pass fully for wasm2js, which is the only user I know of these passes.

[kripken]

I think this makes sense to me. I don't see a problem, at least.

To get more confidence, perhaps run the binaryen fuzzer locally, specifically the wasm2js one there.

[sbc100]

I think this makes sense to me. I don't see a problem, at least.

To get more confidence, perhaps run the binaryen fuzzer locally, specifically the wasm2js one there.

I'm not sure I've ever done that before. looking it up now.. What would the failure mode be that I am looking for?

[sbc100]

Looks like we might need to enable these features in the wasm2js fuzzer first: #9024