Benchmarks: Prevent cross-module inlining of f32/f64 @_extern(wasm) functions

[krodak]

Overview

Applies @inline(never) wrappers to _swift_js_push_f32, _swift_js_push_f64, _swift_js_pop_f32, and _swift_js_pop_f64 to prevent a Swift 6.3-dev compiler bug where cross-module inlining of @_extern(wasm, module: "bjs", ...) functions causes the Wasm module name to be lost ("bjs" becomes "env"), resulting in link failures when building external packages that depend on JavaScriptKit.

This follows the same pattern already used for _swift_js_pop_pointer.

Issue

wasm-ld: error: import module mismatch for symbol: $s13JavaScriptKit17_swift_js_pop_f32SfyF
>>> defined as env in .../Benchmarks.build/BridgeJS.swift.o
>>> defined as bjs in .../JavaScriptKit.build/BridgeJSIntrinsics.swift.o

All four f32/f64 functions are affected: _swift_js_push_f32, _swift_js_push_f64, _swift_js_pop_f32, _swift_js_pop_f64.

Why CI doesn't catch this

CI runs make unittest and swift test --package-path Plugins/BridgeJS, both of which compile within the same package. The bug only manifests when a separate SwiftPM package depends on JavaScriptKit in release mode, triggering cross-module inlining.

Reproduction

# Main
cd Benchmarks
swift package --swift-sdk <wasm-sdk> js -c release
# wasm-ld: error: import module mismatch for symbol ...

# This branch
cd Benchmarks
swift package --swift-sdk <wasm-sdk> js -c release
# Build of product 'Benchmarks' complete!

[kateinoigakukun]

I'll find a time to fix the root cause in the compiler side...