[google_maps_flutter] Create SDK 9 and 10 packages for iOS

[stuartmorgan-g]

Implements approach E.1b from the design doc 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 [google_maps_flutter_ios]: Add swift package manager compatibility #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

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

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. ↩ ↩² ↩³

[stuartmorgan-g]

Review note: I had to do a bunch of squashing to reconcile the combined branch with what I split out into #10839, and accidentally destroyed the separation between "create _sdk9 as a direct copy that doesn't need review" and "edit _sdk9 to change what needs to be changed". aeaecee is the version of that for making _sdk10 from _sdk9 though, which shows what the diffs mostly looked like. Vanilla to _sdk9 also had some extra podspec changes to make the podspec version-specific in the first place, and created Swift.package entirely, so those two files should be reviewed in full.

Other than those diffs, you should be able to essentially ignore _sdk9 and _sdk10 files in review, as they are copies.

[stuartmorgan-g]

This is the same thing we used to do for camera_android. It only affects the build-all test; we still build each individual package's example, so we are getting full coverage that each variant is buildable.

[stuartmorgan-g]

Sorry for the churn; I should have started it as a draft while I ironed out the bits I missed locally. This is now passing CI and ready for review.