[iOS] Declare executorch SwiftPM system-framework dependencies

[mergennachin]

Problem

The executorch SwiftPM product currently declares only the C++ standard library. With -all_load, static initializers and the image extension can pull symbols that require Accelerate, CoreGraphics, CoreImage, CoreVideo, and Foundation. Requiring each application to add a partial workaround is incomplete and duplicates package-owned linkage details.

This was identified while reviewing the iOS documentation in #22620. The manifest change is intentionally excluded from that documentation-only PR.

Proposed change

Declare Accelerate, CoreGraphics, CoreImage, CoreVideo, and Foundation on the executorch product in Package.swift.

Test plan

• Run swift package --disable-sandbox dump-package.
• Build a minimal SwiftPM consumer with the executorch product and -all_load.
• Run iOS framework and demo-app CI.

cc @larryliu0820 @GregoryComer @shoumikhin @cbilgin

[shoumikhin]

Opened #22711 for the root manifest.

I reproduced this against the published prebuilt frameworks. A package depending on the
executorch product alone, linked with -all_load, fails with 16 missing symbols, 8 from
vImage and 8 from Core Image.

Two notes from measuring it, both of which changed what I first wrote in the PR.

Accelerate and Core Image are the two that fix the link for most consumers. Core Graphics,
Core Video and Foundation usually arrive as link hints instead, either from the Swift files
in the framework or from the consumer's own code when it is built with modules enabled,
which is the default. An Objective-C consumer with modules off gets no such hints and does
need Core Graphics and Core Video named as well, so all five are worth declaring. The same
five are already named in the CMake build of the image extension, but CMake passes them on
the final link line, and an xcframework has nowhere to carry that, so the manifest has to
say it again.

The other note is why the PR says "Part of" and not "Fixes". Prebuilt-binary users get
their manifest from Package.swift.template on the swiftpm branch, not from the root
Package.swift, and that template carries the same executorch entry with only c++. So
the PR does not reach the people most likely to hit this. I will send the matching change
against that branch next, and this issue should stay open until then.

Two smaller things. Static initializers are not involved: none of the image object files
has one, so the symbols come in through -all_load or from calling the image processor.
And executorch_llm and executorch_dump have the same gap for a different reason: they
depend on the bare binary target rather than the one carrying the linker settings, so a
consumer of executorch_llm alone is missing libc++ too. That looks like a separate fix.

[shoumikhin]

Opened #22723 for the template on the swiftpm branch, which is the half that reaches
prebuilt-binary users. Same seven lines as #22711.

Verified it the way the release job does: rendered the template with a published
nightly's version and checksums, then ran swift package describe. It passes, and a
package depending only on the executorch product links and runs against the published
frameworks. Removing the added block brings the 16 missing symbols back.

Both changes declare the frameworks on executorch because that is the only place the
current packaging allows. #22722 tracks the better shape, giving the image processor its
own product so the core runtime stops carrying those dependencies.