Enable Swift testing in the iOS embedder (#185712)

This patch:
1. Updates the `-mios-simulator-version-min` ldflag to `15.0` (this
fixes the crash during test discovery).
2. refactors swiftc.py a bit, moves the target triplet logic from
darwin/BUILD.gn to swiftc.py so you can override the ios version in a
test target (but it's not absolutely necessary for this change since
it's the linker flag that makes the difference).
3. Migrates a few xctest tests to swift testing tests. The names of the
tests are kept as-is so the diff is easier to read.


### The Crash 
```
(lldb) bt
* thread #9, name = '[Swift Testing] test discovery - loading test #0 (Task 3)', queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000000000000 
    frame #1: 0x000000010ad0fb80 libios_test_flutter.dylib`closure #1() in variable initialization expression of static AccessibilityFeaturesTests.$s22ios_test_flutter_swift26AccessibilityFeaturesTestsV43accessibilityFeatureFlagRawValuesAreCorrect4TestfMp_24accessorc8120add5c86a9e3fMu_ at @__swiftmacro_22ios_test_flutter_swift26AccessibilityFeaturesTestsV43accessibilityFeatureFlagRawValuesAreCorrect4TestfMp_.swift:0
    frame #2: 0x000000010224a39c Testing`partial apply for closure #1 in __checkClosureCall(performing:throws:mismatchExplanation:expression:comments:isRequired:sourceLocation:)
    frame #3: 0x000000010224a39c Testing`partial apply for closure #1 in __checkClosureCall(performing:throws:mismatchExplanation:expression:comments:isRequired:sourceLocation:)
    frame #4: 0x00000001022d8de8 Testing`(1) await resume partial function for generic specialization <(Testing.Test, Testing.Runner.Plan.Action)> of reabstraction thunk helper <τ_0_0 where τ_0_0: Swift.Sendable> from @escaping @isolated(any) @callee_guaranteed @async () -> (@out τ_0_0) to @escaping @callee_guaranteed @async () -> (@out τ_0_0, @error @owned Swift.Error)
    frame #5: 0x000000010224ae24 Testing`closure #1 in __checkClosureCall(throws:performing:expression:comments:isRequired:sourceLocation:)
```

Initially I thought swift testing doesn't support test discovery in
linked dylibs but it's apparently not the case. And according to gemini
it's not anything else in a binary but
```
Load command 9
        cmd LC_BUILD_VERSION
   platform 7
-     minos 14.0
+     minos 15.6
        sdk 26.4
```

As it tried to use `15.6` in `swift_flags` and put `14.0` in `ldflags`
and hit the same crash.

This is what gemini has to say:
> This is the definitive end of the road! 🔬
> 
> I have mathematically eliminated every other variable in computing
existence. Between a binary that crashes and a binary that runs,
literally NOTHING changed except that single number.


Also it thinks it's because of this in `dyld`:
> Look at the code in dyldMain.cpp at Line 430:
> 
> cpp
> // dyldMain.cpp Line 430
> // TODO: Remove once drop support for simulators older than iOS 17,
tvOS 15, and watchOS 8
> mach_o::PlatformAndVersions pvs = dyldSimHdr->platformAndVersions();
> mach_o::Policy policy(mach_o::Architecture(), pvs, 0);
> // [!!] THE SMOKING GUN [!!]
> // Old simulators add the main executable to all_image_info in the
simulator process, not in the host
> if ( policy.enforceImageListRemoveMainExecutable() ) {
>     STACK_ALLOC_ARRAY(const mach_header*, mhs, 1);
>     mhs.push_back(state.config.process.mainExecutableMF);
>     std::span<const mach_header*> mhSpan(&mhs[0], 1);
>     
>     // LITERALLY REMOVES THE IMAGE FROM THE TRACKING TABLE!!
> state.externallyViewable->removeImages(state.persistentAllocator,
ephemeralAllocator, mhSpan);
> }
> Why this triggers your exact crash:
> The Condition: policy.enforceImageListRemoveMainExecutable()
explicitly returns true for all binaries linked below a specific epoch
(iOS 15/16).
> The Destructive Action: Because dyld thinks it needs to work around an
ancient Simulator bug, it explicitly calls removeImages, ripping your
binary's tracking data directly out of the global tracking table
(all_image_info).
> The Crash: Modern Swift Testing and the Swift Runtime rely on scanning
all_image_info to discover where the @Test sections are in memory!
> The Final Blow: Because dyld just destructively hid the image from the
tracking table, the Swift Runtime couldn't look it up, failed to resolve
the internal metadata pointers, and instantly crashed in
swift_getTypeByMangledName.
> By simply lying and writing minos 15.0 into the header, you caused
policy.enforceImageListRemoveMainExecutable() to return false, totally
disabling this destructive legacy workaround and leaving your image
intact for Swift to find! 🔬🏆🏁

## Pre-launch Checklist

- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [AI contribution guidelines] and understand my
responsibilities, or I am not using AI tools.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [ ] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel
on [Discord].

If this change needs to override an active code freeze, provide a
comment explaining why. The code freeze workflow can be overridden by
code reviewers. See pinned issues for any active code freezes with
guidance.

**Note**: The Flutter team is currently trialing the use of [Gemini Code
Assist for
GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code).
Comments from the `gemini-code-assist` bot should not be taken as
authoritative feedback from the Flutter team. If you find its comments
useful you can update your code accordingly, but if you are unsure or
disagree with the feedback, please feel free to wait for a Flutter team
member's review for guidance on which automated comments should be
addressed.

<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[AI contribution guidelines]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md