[in_app_purchase] Propagate launchBillingFlow failures

[mklim]

Description

Previously the buy methods were just returning void, so the immediate
response of BillingClient#launchBillingFlow was unaccessible. Change
it to return a Future<bool> and return whether or not the launch flow
succeeded in google_play_connection. Always return true in
app_store_connection since there's no equivalent status there.

Related Issues

flutter/flutter#31417
Fixes flutter/flutter#32518
flutter/flutter/issues/32512

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• 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.

[cyanglaz]

LGTM! Left some comments

[LinusU]

@mklim did you consider returning a Future<void> that rejects with an error in case initiating the flow doesn't succeed?

I think that as it is now, it will be easy to accidentally miss handling this. E.g. since this function used to return void, I think that many people will not check the return value, and thus the error will go silently ignored instead of showing up as an unhandled exception in the debugger.

In general I feel that returning bools wheter an error occured or not isn't the best API design in a language that has native exceptions (and, in this case, native Futures with rejections).

Maybe I've missed something though? ☺️