[google_sign_in] Redesign API for current identity SDKs

[stuartmorgan-g]

This is a full overhaul of the google_sign_in API, with breaking changes for all component packages—including the platform interface. The usual model of adding the new approach while keeping the old one is not viable here, as the underlying SDKs have changed significantly since the original API was designed. Web already had some only-partially-compatible shims for this reason, and Android would have had to do something similar; see flutter/flutter#119300 and flutter/flutter#154205, and the design doc for more background.

• Fixes [google_sign_in] Rework google_sign_in to reflect changes in underlying SDKs flutter#119300
• Fixes [google_sign_in] Switch Android to Credential Manager flutter#154205
• Fixes [google_sign_in_web] Enable incremental authorization for Code Model. flutter#139406
• Fixes [google_sign_in_android] Remove deprecated API usages in most recent version of play-services-auth flutter#150365
• Fixes [google_sign_in_web] Remove deprecated signIn method. flutter#137727
• Fixes [google_sign_in] Implement canAccessScopes on mobile flutter#124206
• Fixes google_sign_in plugin links to obsolete documentation for web flutter#117794
• Fixes [google_sign_in] Android documentation is wrong flutter#107532
• Fixes [google_sign_in] Support passing a nonce flutter#85439
• Fixes [google_sign_in] java.lang.NullPointerException: Attempt to read from field [...] on a null object reference flutter#74308
• Fixes [google_sign_in] Add future that completes when the plugin is (really) ready. flutter#71607
• Fixes [google_sign_in_web] googleSignIn.signIn() hangs forever if can't connect to apis.google.com flutter#70427
• Fixes [google_sign_in] better error handling flutter#32441 (there may be more to do here over time, since we may find exceptions that are not caught, but we now have a structured system to convert errors to as we find specific unhandled cases)

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

[ycv005]

Waiting for this.