BridgeJS: Swift closure support

[krodak]

Overview

This PR implements typed closure support in BridgeJS, enabling Swift functions to accept closures as parameters and return closures as values with full type safety.

Example

Swift:

@JS class TextProcessor {
    @JS init(transform: @escaping (String) -> String)
    @JS func processWithPerson(_ person: Person, formatter: (Person) -> String) -> String
    @JS func makePersonCreator(defaultName: String) -> (String) -> Person
}

JavaScript:

const processor = new exports.TextProcessor((text) => text.toUpperCase());

const person = new exports.Person("Alice");
const result = processor.processWithPerson(person, (p) => `${p.name}: ${p.greet()}`);

const creator = processor.makePersonCreator("Default");
const p1 = creator("Bob");

TypeScript:

export interface TextProcessor extends SwiftHeapObject {
    processWithPerson(person: Person, formatter: (arg0: Person) => string): string;
    makePersonCreator(defaultName: string): (arg0: string) => Person;
}

Technical Changes

• Extended type system to support BridgeType.closure(ClosureSignature)
• Updated Swift parser to detect closure parameters in function declarations
• Generate Swift helper enums (_BJS_Closure_*) for each unique closure signature
• Generate JavaScript callback registry and invoke functions, needed to expose _exports and _bjs to support that
• Map closure signatures to TypeScript function types
• Automatic memory management in both directions, needed to add bridgeJSLowerParameterWithRetain to support optional SwiftHeapObject

Supported Features

• ✅ Closure parameters with any supported type
• ✅ Closure return values
• ✅ @escaping closures
• ✅ Optional closures and optional parameters/returns
• ✅ All existing BridgeJS types (primitives, String, enums, Swift classes)
• ❌ Closure-typed properties (parameters/returns only)
• ❌ Async/throwing closures

Testing

Added comprehensive snapshot and runtime tests for closure parameters, returns, optionals, and Swift heap objects in closures.

Documentation

Extended current documentation with new Exporting-Swift-Closure.md

[kateinoigakukun]

To be conservative, it might be better not to force lowercase here to avoid conflicts with names having different casing

[kateinoigakukun]

Can we encode the module name into the mangled name to avoid conflicts with the same name types from other modules?

[kateinoigakukun]

Suggested change

	return "Optional\(wrapped.mangleTypeName)"
	return "Optional<\(wrapped.mangleTypeName)>"

Let's include angle bracket not to conflict with user defined OptionalFoo nominal types

[krodak]

This is used for functions and classes name, so we need to avoid < > as this would be treat as generics - maybe we should settle for something like: return "Optional_\(wrapped.mangleTypeName)"

That would also align with

case .closure(let signature):
            return "Closure_\(signature.mangleName)"

[kateinoigakukun]

Hmm, I think it still has ambiguousity. How about using Swift's mangling rule here? It's very simple if we just want to mangle it. (demangling might be tricky but)
https://github.com/swiftlang/swift/blob/main/docs/ABI/Mangling.rst#types

[kateinoigakukun]

I think we already have swift_js_release, which does exactly the same thing

[kateinoigakukun]

Can we consider replacing this class with JSObject? JS object handle deallocation is a bit tricky (e.g. we need to care about deallocation from other threads than it was created.), so I'd like to centralize the lifetime management in JSObject.