Runtime-copy: flag AbortSignal.any precisely (not all of UsesAbortController)

[nickna]

Background

Introduced in #115. The compiler now records a semantic "needs-SharpTS-at-runtime" signal (EmittedRuntime.RequiredSharpTSRuntimeReasons, surfaced via ILCompiler.RequiredSharpTSRuntimeReasons) so the CLI co-locates SharpTS.dll with compiled output only when a feature genuinely late-binds into the runtime on its normal path (eval, Proxy, Intl, vm, dns, @DotNetType dynamic events).

The gap

AbortSignal.any late-binds to RuntimeTypes.AbortSignalAnyCompiled and so genuinely requires SharpTS at runtime. But its emission is gated only by the coarse RuntimeFeatureSet.UsesAbortController flag — which is also set by ordinary AbortController/fetch(..., { signal }) usage that is pure IL and needs no runtime.

Flagging all UsesAbortController would force an unnecessary SharpTS.dll copy for the common AbortController+fetch case, defeating the "only when needed" goal. So #115 deliberately left AbortSignal.any unflagged — meaning a program that actually uses AbortSignal.any and runs truly standalone will hit graceful degradation (throw) instead of having SharpTS.dll co-located.

Proposed fix

Add a precise feature flag (e.g. UsesAbortSignalAny) set by the RuntimeFeatureDetector only when AbortSignal.any is referenced, then record the runtime reason on that flag (runtime.RequireSharpTSRuntime("AbortSignal.any")) rather than on UsesAbortController. This keeps basic AbortController standalone while correctly co-locating SharpTS.dll for AbortSignal.any.

Acceptance

• A program using only AbortController (incl. fetch with a signal) → no SharpTS.dll copy.
• A program using AbortSignal.any([...]) → SharpTS.dll co-located; reason AbortSignal.any reported.

Low priority — AbortSignal.any is rare and degrades gracefully today.