[url_launcher] Add non-browser URL launch mode for Android

[Mosc]

Adds support for LaunchMode.externalNonBrowserApplication to url_launcher on Android by acting on the universalLinksOnly parameter that was already being passed to the method channel. Simply adds Intent.FLAG_ACTIVITY_REQUIRE_NON_BROWSER on Android R and up, but requires a fallback on lower versions. The fallback works by querying the package manager for which apps can handle the intent, and only considering those apps that don't handle just any HTTPS URL. If the resulting list is non-empty, a suitable non-browser app has been found.

Fixes flutter/flutter#66721.

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. (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, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this 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]

Thanks for the submission! We'll need to hold off briefly on reviewing this, since we should do #5966 first. That will allow implementing this for the new functionality without changing the legacy API's behavior on Android (which we don't want to do since that legacy API is very iOS-centric). It will also mean that the Android implementation doesn't need to use the iOS term internally, which may be confusing for maintenance.

[stuartmorgan-g]

This change will need to be a separate PR, since you need to update the minimum Android implementation package version to say this.

[stuartmorgan-g]

The PR referenced above has landed, so you can update this to implement the new API now. (It won't currently work from the app-facing package, but that will be resolved shortly with #5985 so development of this can proceed in parallel.)

[stuartmorgan-g]

The app-facing package PR has also landed, so an updated version of this would work end to end.

[stuartmorgan-g]

@Mosc Are you planning on updating this PR to implement use the new API?

[Mosc]

Yes, but it's bit low on my priority list, and with limited time available I haven't got around to restructuring the PR yet. I would not mind if you or someone else takes over in the meantime.

[Hixie]

@Mosc I'm going to close this PR for now to get it off our review queue, but please don't hesitate to submit a new PR if you have the time to get back to it. In the meantime I'll mention this PR on the issue so that anyone else who wants to pick it up can do so. Thanks again for your contribution!