Raise wasm C stack size so deep recursion no longer traps (fixes #47)

[paulmanoni]

Problem

Evaluating deeply‑nested expressions traps with wasm error: out of bounds memory access instead of completing (or returning a catchable error). It's a C call‑stack overflow: QuickJS's parser/evaluator recurse in C, and the qjswasm target linked with wasm‑ld's small default stack.

The ceiling is low enough to hit real code:

• plain Eval of ~1000 nested parens traps;
• via @vue/compiler-sfc (which adds its own recursion on top of the source AST) it traps at only ~15–20 levels of ordinary source nesting — array/object config literals with arrow callbacks, ternaries, optional chaining, etc.

Fixes #47.

Root cause

--stack-first and --initial-memory are added via add_link_options(...) after add_executable(qjswasm) in qjswasm.cmake, so they never apply to that target (add_link_options only affects targets created after it). The effective link therefore used wasm‑ld's default stack size.

Fix

Move the stack sizing into the target_link_options(qjswasm PRIVATE ...) block that actually applies to the target:

"LINKER:-z,stack-size=16777216"     # 16 MiB C stack (was wasm-ld's small default)
"LINKER:--initial-memory=20971520"  # 20 MiB — with --stack-first the stack lives at the
                                     # bottom of linear memory, so initial memory must
                                     # exceed stack-size + data

qjs.wasm regenerated via make + wasm-opt -O3 (WASI SDK 33).

Verification

• Nested‑paren Eval now succeeds to depth 20000 (previously trapped at 1000).
• A real 128‑component Vue app compiled through @vue/compiler-sfc on qjs: 10/128 files failed before, 0/128 fail now.

rt, _ := qjs.New(qjs.Option{MaxStackSize: 8 << 20, MemoryLimit: 1 << 30})
code := strings.Repeat("(", 5000) + "1" + strings.Repeat(")", 5000)
_, err := rt.Context().Eval("x.js", qjs.Code(code)) // before: panic; after: ok

Notes / follow‑ups (not in this PR)

• 16 MiB is a pragmatic default; happy to tune.
• Separately, it would be nice if a wasm trap from (*Runtime).call returned an error instead of panic-ing (today a single deep Eval can crash the host and poison the runtime), and if QuickJS's own JS_SetMaxStackSize guard were coupled just under the linker stack so true runaway recursion throws a catchable RangeError. Glad to do those in a follow‑up if you're interested.