Fix Android plugin: Handle intent and provide result if the intent is consumed

[relaxedSoul]

Context

When the Android OS opens the application with deeplink/applink (to simplify - applink), they are provided to the app inside the Intent.
The app can already be running and the Activity is in the foreground, registered to handle the Intent with a specific intent filter. The applink will be delivered by the method onNewIntent.
Flutter provides a way to handle such links - the flutterPlugin or flutterEngine should implement the interface onNewIntentListener.

The bug

The audio service implements this interface, but if the applink is supposed to be delivered to another plugin, its listener will not be called, because the audio service listener always returns true from the function onNewIntent.
If another listener waits for intent, it will never receive it, even if the applink was not for audio service, but for another purpose.

Where it happens

AudioServicePlugin.java -> onAttachedToActivity method.
The method registerOnNewIntentListener() is called, and from now on, the intents will be handled by newIntentListener.
The implementation of the interface, its single method, always returns true.
The value returned here is used by Flutter (OS, eventually) to call or not call the next listener in the... I don't know if a list or a stack. I believe in the list (FIFO).
The result true signs that the intent was consumed, and no other listeners should be called.

Fix

As far as I see, there is a method inside that makes the check, and if it fails, the intent is not handled at all. I believe this check also should deliver the result "is handled" back to the caller, and the result should be returned.

Issues or tickets, or PRs in repo

I couldn't find anything related to this bug, but there is a chance the changes will solve some other bugs: the onNewIntent handling can have a large impact on various plugins, which depend on app link handling or deeplinks.

Pre-launch Checklist

• I read the CONTRIBUTING.md and followed the process outlined there for submitting PRs.
• My change is not breaking and lands in minor branch OR my change is breaking and lands in major branch.
• If I'm the first to contribute to the next version, I incremented the version number in pubspec.yaml according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
• I updated/added relevant documentation (doc comments with ///).
• I ran dart analyze.
• I ran dart format.
• I ran flutter test and all tests are passing.