[url_launcher] add support for android headers

[juliocbcotta]

Description

This PR enables the developer to send headers to the Android browser.
This enables the developer to keep the app session in the browser when the same authentication header is used in the app http requests and the in the web site.

Checklist

• [ X 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 (flutter analyze) does not report any problems on my PR.
• I read and followed the [Flutter Style Guide].
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• 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.

[collinjackson]

I've updated the version to a minor (rather than patch) update because you're introducing a new optional argument.

[collinjackson]

Thanks for the PR!

Since these headers can only be set on Android, the documentation will need to be updated to reflect this.

[amirh]

I'm not sure I understand why are we overriding this to call loadUrl on versions older than Lolipop?

[juliocbcotta]

You can verify why running the code in different emulators APIs, but the gist of it is that the first method is deprecated and should be used only in older versions of android, at the same time second method only exist in new API versions and they will not call the first one.

[amirh]

Thanks for following up!

I'm still not sure I understand - what breaks if we don't override shouldOverrideUrlLoading at all?

[juliocbcotta]

I don't quite remember, but I guess that is so the user can navigate using hyperlinks.
I didn't included the call to setWebViewClient, I just fixed the deprecation warning I was getting in Android Studio.