As title

## Pre-Review Checklist

**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.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Converts all of the native unit tests in `video_player_avfoundation` to Swift:
- For the UI integration tests, it's just a direct Swift conversion.
- For the unit tests, I first did a direct conversion to Swift, including ensuring that everything passed in that version, then converted from XCTest to Swift Testing.

To minimize churn, I deliberately didn't address other technical debt in the tests (e.g., testing of player instances by making an entire plugin instance just to make a player). Some changes were necessary though:
- Added some missing `NS_ASSUME_NONNULL_BEGIN` annotations to headers, to avoid having to deal with optional values in the Swift version of tests that couldn't ever actually be null.
- Changed a utility method to take the necessary parts of `AVAssetTrack` instead of `AVAssetTrack`. The tests for that worked by subclassing `AVAssetTrack` even though it has no public initializers, which was extremely sketchy. It worked okay in Obj-C because Obj-C will let you get away with almost anything, but it doesn't compile in Swift.
- Some tests that used Expectations to watch for KVO on player items extracted from the player internals have instead been changed to watch for player-level observable events. This is because I was having a lot of trouble getting KVO of `AVPlayerItem` to actually work in Swift, and rather than try to fix that when it wasn't great test design anyway, I just changed to using something that wasn't an internal detail anyway.

Part of flutter/flutter#119105

## Pre-Review Checklist

**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.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

…ns) (#10999)

flutter/flutter@67323de...44a626f

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-stable-packages
Please CC boetger@google.com,stuartmorgan@google.com on the revert to ensure that a human
is aware of the problem.

To file a bug in Flutter (stable): https://github.com/flutter/flutter/issues/new/choose
To file a bug in Packages: https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Updating for cupertino_icons

## Pre-Review Checklist

**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.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

Implements approach E.1b from [the design doc](https://flutter.dev/go/google-maps-spm-versioning) about SwiftPM support. The main changes are:
- Adds a new `google_maps_flutter_ios_shared_code` directory which has an exact copy of almost all of the code files from `google_maps_flutter_ios`.
- Adds a new `tool` directory to `google_maps_flutter_ios` (and the shared code, so that it stays in sync) with two command scripts:
  - `run_tests.dart`, which is automatically run by existing repo tool logic, as part of the custom tests task. This validates that for every file in `google_maps_flutter_ios_shared_code`, the corresponding file in `google_maps_flutter_ios` is identical (modulo some expected package name differences in specific cases). It lists all the files checked, to allow for easy auditing in CI output or locally about what is being shared.
  - `sync_shared_files.dart`, which is a helper script for local use that copies all files in the current package that have changes relative to their shared code counterparts, both to the shared copy and all other copies. This is to make the local development process less painful; for most changes, all someone has to do is work in one of the packages, and then run this script when they are done to sync those changes to all the other copies. It also logs any code files that aren't shared, to remind people adding files to take the step of adding those to the shared copy if they should be shared.
- Adds two new duplicates of `google_maps_flutter_ios`, `..._sdk9` and `..._sdk10'` which are direct copies of `google_maps_ios` with very minor changes:
  - Anything based on the package name is changed/renamed
  - The podspecs are narrowed to use the relevant dependency versions and have the correct min iOS version for that SDK
  - Swift.package entries are added, making the packages SwiftPM-compatible
  - The CHANGELOGs are cleared.
  - The READMEs are updated to explain each package's role/behavior.

There are some minor supporting changes:
- The `google_maps_flutter_ios` README has been adjusted to reflect the new set of options.
- Obj-C code using the Google Maps Utils package has been updated to handle differences in the package name for Obj-C (adapted from #8288). I created a trampoline header to deal with this difference rather than inline the `#if` and explanation in each file.
- Dart test code has been updated to use a non-shared trampoline header to localize the import diffs due to different package names to a tiny non-shared file. (We could switch this to using the file rewriting logic that I ended up having to add to `sync_shared_files.dart` later; I left it this way to minimize the number of files we have to do rewriting in, but I'm fine with either option.)
- The Pigeon configuration forces a specific package name instead of auto-determining it. Pigeon currently uses the package name as part of the channel name for each call, so doing this avoids tons of unnecessary diff in the generated files. (This does mean that the different implementation packages are all using the same channel names, but that should be safe since `flutter` should only allow one of the implementations to be registered.)

Once this lands and the new packages are published, I will do a follow-up PR to add a `google_maps_flutter` README discussion of how and why to use these new packages.

Mostly completes flutter/flutter#146920

## Pre-Review Checklist

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

also opts in go_router

## Pre-Review Checklist

**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.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

…nored (#10991)

Fixed a regression in `2.9.1` where `httpHeaders` were ignored on iOS.

Fixes flutter/flutter#182015

**The Fix**:
Updated `FVPAVFactory.m` to use `[AVURLAsset URLAssetWithURL:options:]` instead of `[AVAsset assetWithURL:]`. The previous implementation dropped the `options` dictionary containing the headers.

**Verification:**
Verified manually with Wireshark.
* **2.9.1:** Headers missing.
* **2.9.2 (Fix):** Headers present.

## Pre-Review Checklist