feat(firestore): Swift Package Manager support

[russellwheatley]

Description

• Created a symlinked shared firebase_core Swift package on code that is required for Firestore (and every other FlutterFire plugin). The way this works:

1. Package.swift file in the root of repo: https://github.com/firebase/flutterfire/blob/main/Package.swift
2. Packages this code: https://github.com/firebase/flutterfire/tree/main/Sources
3. We exclude this shared code from firebase_core Package.swift to negate duplicate symbols: https://github.com/firebase/flutterfire/pull/13329/files#diff-8ba779f9dea534ccdcb7bea8d78060e805ad75ef984ad7ce64d49c947ab76f16R111-R114
4. This allows firebase core existing code to remain intact for Cocoapod builds.
5. Shared package is depended on by every plugin's Package.swift file. E.g: https://github.com/firebase/flutterfire/pull/13329/files#diff-8ba779f9dea534ccdcb7bea8d78060e805ad75ef984ad7ce64d49c947ab76f16R99
6. Versioning of package occurs post melos version: https://github.com/firebase/flutterfire/blob/main/melos.yaml#L25
7. Tag will be pushed to repo as part of release cycle. i.e. git push --tags. Tag looks like 3.6.0-firebase-core-swift. I would've like to use existing firebase core tag but it isn't semantically correct as Swift requires version first whilst our current tag looks like firebase_core-v3.6.0 (i.e. version last).
8. I've created a pre-commit hook for melos to create a simple txt file with the latest firebase-ios-sdk version. The dart script will update the version for cloud_firestore, it will only create or update the generated_firebase_sdk_version.txt file if the package has a Package.swift file (i.e. supports Swift), it also ignore firebase_core plugin as it already has the canonical firebase_sdk_version.rb version file.
9. Headers are if/else'd due to shared package in different location. macOS firestore build didn't like modular imports for header files either.
10. Switched to testing Swift builds with Dart rather than shell script. Should be easier to manage.
11. Swift package manager usage will only work if all FlutterFire dependencies in your app have been migrated to support Swift. Otherwise, you'll likely get duplicate symbols as you're bringing in core from Swift and Cocoapods. At the moment, it is just core + firestore.

Related Issues

Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (melos run analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change.
• No, this is not a breaking change.

[Lyokone]

Will we need to do the other packages? Or is it just because cloud_firestore has its own SPM package?

[russellwheatley]

Yeah, it's just for the packages which have Swift support; core + firestore.