GeezerVison

SwiftInteropBenchmarks.js times matched operations through the
Objective-C/C metadata path and through Swift thunks:
- a function;
- class and instance methods;
- a string round trip;
- object construction;
- a property read.

It writes the results to Documents/swift-bench.txt and asserts nothing.
The fixture gains the Swift counterparts.

The benchmarks showed instance calls and property accesses copying their
member group on every call to filter a generic family's overloads by
receiver. Groups now record whether they mix owners, and only those are
filtered. With that, the Swift path matches or beats the Objective-C path
in a Debug simulator build (docs/swift-interop.md has the numbers).

Apps list the Swift modules JavaScript uses in NS_SWIFT_MODULES, in
App_Resources/iOS/build.xcconfig. SDK modules, SwiftPM packages and the
app's own module are all supported.

At link time, nsld.sh (iOS and visionOS templates) runs the new
build-step-swift-interop.py for each architecture, next to the
Objective-C metadata step:
- it extracts the modules' symbol graphs from the build products and the
  SDK;
- it generates and verifies them as one unit;
- it compiles the thunks to an object;
- it hands nsld the object and a -u flag per register symbol to link.

The script ships beside build-step-metadata-generator.py, so the CLI
needs no change.

Checked against Xcode-shaped environments: the SwiftDemo/SwiftDemoKit
modules and WeatherKit each produce an object that exports its register
symbols. A full `ns build` against a packed runtime has not been run yet.

The app build step now passes the app's header search paths to symbol
graph extraction and to the thunk compile, so clang modules from plugin
sources resolve. One example is @nativescript/core's NativeScriptEmbedder,
which an app's Swift module imports. Relative search paths are resolved
against SRCROOT, since the step runs from the metadata generator's
folder.

Validated with an app: the app's own Swift module plus WeatherKit, built
through `ns build ios` with the packed runtime. Debug and Release
simulator builds both pass a startup check of every ns:swift feature.

The app build step keys the generated object on a hash of the extracted
symbol graphs, the generator binary, the step itself, and the generator
and compiler command lines. A relink with the same key reuses the
previous object instead of regenerating, verifying and recompiling, so an
unchanged module costs only its symbol graph extraction.