BridgeJS: Fix argument order for stack-lowered imported parameters

[krodak]

Overview

Imported parameters that push onto the shared value stacks are lowered in reverse declaration order, because the JavaScript side pops them in declaration order and the stacks are LIFO. CallJSEmission selected that bucket with loweredParameters.isEmpty, which is wrong for a parameter that does both: an optional container passes an isSome discriminator as a wasm parameter and its payload on the stack, so it was emitted in forward order ahead of everything in the reversed bucket.

Combining one with any other stack-lowered parameter therefore transposed the arguments. With [String: V]?, a @JS struct?, or a @JS enum with associated values it is worse than a transposition: the array codec reads the other parameter's scalar as an element count and builds a garbage-length array.

Every parameter is now lowered into stackLoweringStmts in reverse declaration order, so there is one order rather than two and no per-type judgement to keep in sync. The JavaScript side is unchanged, and the 21 changed snapshots are a pure reordering of independent scalar lowerings.

Before / after

@JSFunction func f(_ a: [Int]?, _ b: [Int]) throws(JSException) -> Int

f([1, 2], [7, 8, 9])   // before: JavaScript received f([7, 8, 9], [1, 2])

// before — a's payload is pushed first, so JS pops it as b
let aIsSome = a.bridgeJSLowerParameter()
let _ = b.bridgeJSLowerParameter()

// after
let _ = b.bridgeJSLowerParameter()
let aIsSome = a.bridgeJSLowerParameter()