[webview_flutter] add COMMON support for Android WebView initializing

[dotcink]

Add a common way to initialize Android WebView (make more settings) in Android code.

In most cases, an APP has custom common WebView initialization logic, like WebSettings#setBuiltInZoomControls(boolean), WebSettings#setMixedContentMode(int), WebSettings#setTextZoom(int) etc.
Adding all these settings to Flutter WebView params is tedious, and unnecessary mostly,
or else we can put these initialization on our APP's self native code as below:

FlutterWebView.setCommonIniter(new FlutterWebViewIniter() {
    @Override
    public void initWebView(WebView webView) {
        WebSettings settings = webView.getSettings();
        settings.setMixedContentMode(WebSettings.MIXED_CONTENT_COMPATIBILITY_MODE);
        settings.setSupportZoom(true);
        settings.setBuiltInZoomControls(true);
        settings.setDisplayZoomControls(false);
    }
});

Fix flutter/flutter#70731, flutter/flutter#48283, flutter/flutter#43595, etc.
Related PRs: #2468, #3325, #3701, #2451

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 Flutter Style Guide and the C++, Objective-C, Java style guides.
• 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.

[dotcink]

@amirh @mklim @iskakaushik Please Take A Look.
Thank you.

[stuartmorgan-g]

Thanks for the submission! We’re currently working through a large backlog of PRs, and this will require non-trivial review, so it will take some time before we’re able to review it. As explained in CONTRIBUTING.md, votes for the corresponding issue are the primary way we’re prioritizing non-trivial reviews, so we encourage you to file an issue and associate it with this PR.

[stuartmorgan-g]

(As a quick initial note, I'm not sure this is a direct we would want to take; generally Flutter developers expect to be able to control plugin behavior from Dart, in a cross-platform way; this does not allow for either.)

[dotcink]

Thanks for the submission! We’re currently working through a large backlog of PRs, and this will require non-trivial review (since we need to evaluate whether there are API changes we need to make at the same time), so it will take some time before we’re able to review it. As explained in CONTRIBUTING.md, votes for the corresponding issue are the primary way we’re prioritizing non-trivial reviews, so we encourage you to file an issue and associate it with this PR.

I've associated this PR to some existing related issues, like flutter/flutter#70731.

[dotcink]

(As a quick initial note, I'm not sure this is a direct we would want to take; generally Flutter developers expect to be able to control plugin behavior from Dart, in a cross-platform way; this does not allow for either.)

However, many settings, like mixedContentMode, are Android specific, and adding all WebSettings setters to flutter WebView params is tedious.
For iOS, we might set up WKWebView in plist file, like NSAllowsArbitraryLoadsInWebContent, this PR provides a plist alternative solution.

[LongXiangGuo]

At present, websettings lacks many functions, and its behavior is quite different from that of IOS. It is recommended to agree to the change of PR and wait until webview_flutter had all these settings are satisfied, the initWebView method can be deprecated.

[stuartmorgan-g]

Thanks for the submission, but based on recent discussions the team has had about how we want to structure platform-specific plugin logic, this is not an approach we will be going with. A rewrite is underway that will make it much easier to add Android-specific settings where necessary.

(In general, however, we want to make configuration, and defaults, consistent across platforms as much as possible. E.g., the right solution for the zoom controls in your example was to build the defaults into the plugin for consistency, and provide cross-platform options for changing them, not requiring all developers to add native code to their project to do that themselves.)