Compiled generator/async-generator fixes: #547, #631, #542, #583

[nickna]

Fixes four compiled-mode generator / async-generator issues. All are compiled-only — the interpreter uses an independent model and is unaffected. Each issue is a separate commit.

#547 — for-in with yield stops after the first key

The generator MoveNext emitter hoisted the for-of enumerator across yields but kept the for-in key list + index in IL locals, which a MoveNext re-entry wipes. Mirror the for-of treatment: GeneratorStateAnalyzer records for-in loops whose body yields, HoistingManager allocates a key-list field + index field per such loop, and GeneratorMoveNextEmitter.EmitForIn reads/writes both from those fields.

#631 + #542 — truly-async, serialized async-generator next()

The compiled async generator drove its body synchronously (MoveNextAsync().AsTask().GetResult()), so a not-yet-settled await deadlocked the event-loop thread (#631), and concurrent/re-entrant next() recursed into MoveNextAsync (only kept from overflowing by a reject-on-busy guard, never queued — #542).

• next() no longer blocks: it drives one step and returns the Task<object> built by an emitted AsyncGeneratorBuildResult helper.
• Requests serialize on a per-generator _pendingTail task chain (ECMA-262 §27.6.3 AsyncGeneratorQueue modeled as a Task chain) — overlapping next() calls run FIFO. A synchronously re-entrant next() still rejects with a TypeError to avoid a stack overflow (the self-reentrant case would deadlock under a real queue anyway).
• for await…of now suspends on the iterator protocol via the async state machine instead of blocking (AsyncStateAnalyzer reserves a suspension state for each implicit next()/return() await; a try enclosing a for await takes the flag-based path so its resume labels aren't branched into).
• AsyncGeneratorAwaitContinue no longer short-circuits on the awaited task's fault, so a pending rejection reaches the body's own resume point and its try/catch (also unblocks the pending sub-case of Async generator: a rejected await inside a try is not caught by that try's catch (both modes) #617).

#583 (part 1) — lift capturing nested generator/async functions

Two layers:

1. Calling a capturing arrow inside a generator threw "Non-static method requires a target" (the sync generator emitter bound a null $TSFunction target and never built the display instance). GeneratorMoveNextEmitter now has the capturing-arrow handling the async-generator emitter already has.
2. NestedFunctionLifter now lambda-lifts inside-function captures (was module-block only): the captured function-scope bindings become leading parameters of the relocated top-level declaration, forwarded by an in-place arrow. Self-recursive declarations decline cleanly (a compiled arrow snapshots captures by value, and the forwarding arrow's own let is in TDZ at creation). Compiled: capturing nested generator/async/state-machine-nested functions still not lowered (lifting limitation) #583 §2 (relocated identity shared across enclosing-call instances) remains.

Tests

• New shared (interp+compiled) tests for each fix in GeneratorTests, AsyncGeneratorTests, GeneratorClosureCaptureTests; the emitter-sync guardrail (EmitterSyncTests) updated for the two new GeneratorMoveNextEmitter overrides.
• Full SharpTS.Tests suite green (12702 passing, 0 failing). Standalone-DLL tests green (the new emitted helpers use only BCL types).

Follow-up gaps filed while here

• Compiled: yield* delegation to a genuinely-async async iterator blocks (synchronous GetResult in the async yield* loop) #688 compiled yield* to a genuinely-async iterator still blocks (same synchronous-drive root, async yield* loop).
• Interpreter: variable declared before a for await…of is 'Undefined variable' inside the loop body #689 / Interpreter: concurrent next() on an async generator throws 'Only instances and objects have properties' #690 interpreter async-generator gaps (var scope in for await body; concurrent next()).
• Compiled: synchronous throw in a for-await body that also awaits (or breaks/continues), inside a try, escapes the catch #691 compiled: a synchronous throw in a for await body that also awaits/breaks, inside a try, escapes the catch (narrow tradeoff of the Compiled async generator hangs on a not-yet-settled (genuinely-async) await #631 for-await fix).
• Compiled: for await…of INSIDE an async generator still blocks on a genuinely-async source (AsyncGeneratorMoveNextEmitter.EmitForAwaitOf) #697 compiled for await…of inside an async generator still blocks on a genuinely-async source (AsyncGeneratorMoveNextEmitter.EmitForAwaitOf — same root cause as Compiled async generator hangs on a not-yet-settled (genuinely-async) await #631, separate emitter; left as follow-up to keep this rework scoped to Compiled async generator hangs on a not-yet-settled (genuinely-async) await #631's filed repro).

[nickna]

Rebased onto current main (now MERGEABLE). Two integration notes after the rebase:

• Compiled async generator hangs on a not-yet-settled (genuinely-async) await #631 for-await: main's for-await shared-lowering refactor (Compiler: for await...of over an async generator inside an async arrow emits synchronous IEnumerable iteration (InvalidCastException) #430/Compiled: or await over an async generator inside an async ARROW function throws InvalidCastException (lowered as sync for-of) #645, 2b7fc821) landed after my branch point, moving the lowering to StatementEmitterBase.EmitForAwaitOf. My Compiled async generator hangs on a not-yet-settled (genuinely-async) await #631 suspension fix is kept as a protected override of that shared base in AsyncMoveNextEmitter — async functions suspend; the shared base still blocks for async arrows and async generators (the latter tracked by Compiled: for await…of INSIDE an async generator still blocks on a genuinely-async source (AsyncGeneratorMoveNextEmitter.EmitForAwaitOf) #697).
• Compiled: capturing nested generator/async/state-machine-nested functions still not lowered (lifting limitation) #583 layer 1 (capturing arrow inside a generator) is already fixed on main by Compiled: arrow inside a generator body that writes a captured variable needs a function-level display class (mutation lost) #674 (the base EmitArrowFunction now instantiates the display class). My pre-rebase GeneratorMoveNextEmitter arrow override was dropped as redundant; this PR's Compiled: capturing nested generator/async/state-machine-nested functions still not lowered (lifting limitation) #583 contribution is just the NestedFunctionLifter lambda-lift extension for inside-function captures, which builds on Compiled: arrow inside a generator body that writes a captured variable needs a function-level display class (mutation lost) #674.

Full SharpTS.Tests suite re-run on the rebased state is in progress; the targeted async/generator/closure + emitter-sync suites (264 tests) and all manual repros are green.