BridgeJS: Consolidate optional and pointer runtime intrinsics

[krodak]

Overview

• Refactor pointer-family runtime bridging by introducing _BridgedSwiftUnsafePointerLike and sharing the common lift/lower stack behavior in one protocol extension.
• Add reusable optional helpers and scalar optional bridge protocols (_BridgedSwiftOptionalScalarBridge, _BridgedSwiftOptionalScalarSideChannelBridge) to remove duplicated Optional<Bool/Int/UInt/Float/Double> implementations.
• Consolidate _BridgedAsOptional forwarding for scalar optionals into generic protocol-based extensions while preserving Bool-specific sentinel return lifting.
• Apply helper-based lifting/lowering to additional optional paths (String, JSObject, protocol wrappers, heap objects, case enums) to reduce boilerplate without changing ABI behavior.

[kateinoigakukun]

I've been thinking even more about replacing the optional side channel return with StackABI. Would you mind taking a benchmark if you have a moment?

[krodak]

I'll try to have look at it tomorrow 👍🏻

[krodak]

I tried benchmarking sideChannelReturn vs stackABI for optional scalar returns. Results suggest the side-channel approach is faster.

I used the existing OptionalReturnRoundtrip benchmarks on upstream/main (a98e49d8). Each benchmark calls the method (the default --iterations).

Baseline: 100,000 times per sample, 50 adaptive samples, main.

StackABI variant: modified bridgeJSLowerReturn() on all Optional<T> extensions in BridgeJSIntrinsics.swift to use _swift_js_push_* / i32Stack.pop() instead of _swift_js_return_optional_* / tmpRetOptional*. For example, Optional<Int>:

Full changes and raw JSON results on branch kr/stackabi-optional-benchmark:

• Swift changes: BridgeJSIntrinsics.swift
• JS changes: Benchmarks/bridge-js-stackabi.js (hand-edited from the generated baseline)

Test	sideChannel	stackABI	Change
Int? (some)	2.58	3.11	+20.5%
Int? (none)	2.51	2.49	-0.8%
Bool? (some)	2.44	3.09	+26.6%
Bool? (none)	2.45	2.45	+0.0%
Double? (some)	2.74	3.41	+24.5%
Double? (none)	2.39	2.45	+2.5%
String? (some)	10.50	14.45	+37.6%
String? (none)	2.44	2.56	+4.9%

Maybe we should stick with current side-channel approach where we can for now?

[kateinoigakukun]

Thanks for the data point! In that case, let's stick with the non-stack storage.