Fix #2477: spec-compliant async suspension for await using dispose

[lahma]

Summary

• Refactor DisposeCapability.DisposeResources into a coroutine-style state machine (BeginDispose / ContinueDispose) so the three spec-defined Await(...) suspension points in Explicit Resource Management (3.d.i, 3.e.ii.1, 4.a) become real Promise hand-offs instead of a single synchronous UnwrapIfPromise block.
• Drive the state machine from two integration patterns: Pattern A in JintBlockStatement (suspend the async function via the same machinery as a JS await), and Pattern B (a new DisposeResourcesHelper.DisposeAndThen that chains Promise.then so the function/generator/module return promise is settled only when the dispose chain completes). Pattern B is wired into JintFunctionDefinition.AsyncBlockStart, JintAwaitExpression.AsyncFunctionResume, both AsyncGeneratorInstance resume paths, and SourceTextModule top-level-await execution.

Fixes #2477.

Why

The repro in the issue:

var engine = new Engine(o => o.ExperimentalFeatures = ExperimentalFeature.TaskInterop);
engine.SetValue(\"makeDisposable\", new Func<Task<MyDisposable>>(() =>
    Task.FromResult(new MyDisposable())));
await engine.EvaluateAsync(\"\"\"
    (async () => {
        await using d = await makeDisposable();
    })()
    \"\"\");

hangs and throws PromiseRejectedException: Timeout of 00:00:10 reached even though DisposeAsync() is invoked and completes. The cause is a re-entrancy deadlock between DisposeCapability and EventLoop.RunAvailableContinuations:

1. EvaluateAsync → UnwrapResultAsync fast-path enters RunAvailableContinuations and claims _isProcessing.
2. Draining queues runs the makeDisposable settle, which resumes the async function inline.
3. Body finishes; JintBlockStatement calls DisposeResources. The asyncDispose ClrFunction wraps ValueTask.CompletedTask via ConvertAwaitableToPromise; RegisterPromiseWithClrValue enqueues the resolve, so the promise is still pending.
4. DisposeResources calls UnwrapIfPromise, which polls RunAvailableContinuations — that nested call returns early because _isProcessing == 1. The settle never executes; 10s later the polling loop throws.

Rather than patch the event-loop re-entry guard, this PR makes every async-context DisposeResources call site suspend properly per spec, so no path inside an event-loop continuation needs UnwrapIfPromise on a dispose result.

Test plan

• New Jint.Tests.Runtime.InteropDisposeTests covering: the user's repro via EvaluateAsync, genuinely-async DisposeAsync (Task.Delay), LIFO ordering with multiple await using, nested await using across async functions, SuppressedError chaining, dispose at async function exit, and dispose after unhandled throw.
• Existing ShouldAsyncDispose (sync Evaluate + UnwrapIfPromise entry path) still passes.
• Full Jint.Tests suite: 3004 passed / 0 failed.
• Test262: 184/184 Statements_awaitUsing pass; the broader async/dispose/for-loop sweep shows 3233 pass with only 4 pre-existing failures (AsyncDisposableStack_prototype_disposeAsync) that exist on main and are unrelated to this change.

🤖 Generated with Claude Code