Fix bugs in Dart Implementation of the Pigeon API

[bparrishMines]

Split of #4455

The pigeon implementation and current implementation has potential leaking callbacks when a WebView is disposed. This is a possible cause of flaky tests for WebView, so this PR attempts to prevent callbacks when the corresponding WebView object is disposed. In #4455, the integration tests now seem to pass consistently. Along with fixing the resize test: #4460

This also fixes some trivial bugs found though the integration and widget tests in #4455

Java Portion: #4459

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed 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.
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan-g]

Same.

Would it make sense for all this setup to be done in one central location, perhaps?

[bparrishMines]

I wasn't sure where to do it at. Options that I was considering were:

1. In the constructor of WebView since it is the central class of the plugin. However, this pattern wouldn't be reproducible for plugins where there wasn't a central class.
2. In the constructor of AndroidWebView. However, a user may want to use the android_webview API without using the shared platform interface.
3. It could be done in the plugin registration when it's ready, so this would just be temporary. I could add a TODO if this should be the case.
4. The current solution. I like this one because it only sets the Flutter API when a user starts to use a WebView. I remember that there is a common complaint that Flutter startup is slow because plugin initialization is done for every plugin at startup. This solution follows the idea of initializing only once it is being used.

[stuartmorgan-g]

Is there any real benefit for the setup to be incremental at a per-class-within-the-plugin-level though?

Rather than having the same static and if in every single class, you could have a ensurePigeonApis helper in a separate file that does that check and then calls all of the API setup calls. Then each class could call it (unconditionally) where you currently have all of the logic replicated in each class.

[bparrishMines]

That's a good point. At this small of a plugin, it probably has little to no benefit. I created AndroidWebViewFlutterApis.ensureSetUp.

[stuartmorgan-g]

LGTM