feat: Add experimental closures support with feature flag

[BlobMaster41]

Fixes AssemblyScript#798.
Related: AssemblyScript#173, AssemblyScript#563, AssemblyScript#2054.

Changes proposed in this pull request:

⯈ Added experimental closures feature - Closures can now capture variables from their enclosing scope. This includes support for:

• Capturing parameters and local variables (both let and var)
• Capturing this directly in class methods
• Read and write access to captured variables (reference semantics)
• Multiple closures sharing the same environment
• Deeply nested closures (capturing from grandparent scopes)
• Higher-order functions (map, filter, reduce patterns)
• Factory patterns, memoization, and other functional programming idioms

⯈ Implemented as an opt-in feature flag - Closures are disabled by default to maintain backwards compatibility and expected behavior. Users must explicitly enable the feature with --enable closures. This ensures:

• No changes to existing code behavior
• No additional runtime overhead for code that doesn't use closures
• Indirect calls without closures enabled use simpler codegen

⯈ Added compile-time constant ASC_FEATURE_CLOSURES - Allows conditional compilation based on whether closures are enabled

⯈ Added comprehensive test suites:

• closure.ts - Basic closure patterns (captures, mutations, shared environments)
• closure-stress.ts - Stress tests covering many edge cases (616 lines)
• closure-class.ts - Complex class patterns with closures (1000+ lines) including:
  • State management (BankAccount, Counter)
  • Design patterns (Builder, Factory, Observer, State Machine, Iterator)
  • Inheritance with closures
  • Callback-based async patterns
  • Tree traversal with recursive closures

Implementation Details

The implementation follows the approach discussed in AssemblyScript#798:

Closure Environment:

• Captured variables are stored in a heap-allocated environment structure
• Multiple closures in the same scope share a single environment (reference semantics)
• Nested closures maintain a chain of environments via parent pointers
• Environment structures are managed by the runtime (GC-compatible)

First-Class Functions:

• Function references contain both a table index and an _env pointer
• When calling through a function reference, the _env is loaded and made available
• Non-closure functions have _env = 0, avoiding overhead when closures aren't used

Core changes in src/compiler.ts:

• Pre-scan phase (prescanForClosures) identifies closures and captured variables before compilation
• Environment allocation creates heap-allocated storage for captured variables
• Closure load/store operations route through the environment
• Dynamic Function objects are created with environment pointers for closures
• Feature checks gate closure functionality at detection points
• Indirect calls only set up closure environment handling when the feature is enabled

Supporting changes:

• std/assembly/shared/feature.ts - Added Feature.Closures enum value
• src/common.ts - Added ASC_FEATURE_CLOSURES constant name
• src/program.ts - Registered compile-time constant
• src/index-wasm.ts - Exported FEATURE_CLOSURES for CLI
• src/flow.ts - Added flow tracking for captured variables

Limitations

This is an experimental implementation. Known limitations:

• Performance: Each closure creation involves a heap allocation for the environment

Usage

# Closures disabled (default) - captures produce an error
asc myfile.ts

# Enable closures explicitly
asc myfile.ts --enable closures

// Example closure usage (requires --enable closures)
function makeCounter(): () => i32 {
  let count = 0;
  return (): i32 => {
    count += 1;
    return count;
  };
}

let counter = makeCounter();
counter(); // 1
counter(); // 2
counter(); // 3

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file