fix(cloud_firestore): prevent snapshot race conditions

[Ehesp]

Description

Fixes 2 race conditions:

1. When a snapshot stream unsubscribes, the Dart Stream is removed at the same time an async request to remove the native listener is sent. In some cases, an event is sent from native before the native listener has been removed, but after the Dart Stream is removed, causing an assertion error.
2. If a widget updates in a very short period of time, the onCancel stream handler is called pretty much straight away. Since setting up the stream handler takes longer than removing, in some edge cases it's trying to remove a listener which hasn't been created.

Related Issues

• [cloud_firestore_platform_interface] controller != true #3222
• [cloud_firestore] 0.14.0 Crash when StreamBuilder cancels subscription ( NullPointerException Attempt to invoke ListenerRegistration.remove() on a null object reference / Invalid argument: Instance of 'DocumentReference' ) #3237

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.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
• 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 (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• 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 (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.