[in_app_purchase] Mostly convert to Android Pigeon

[stuartmorgan-g]

Replaces manual method channels with Pigeon.

This replaces all of the method calls in both direction with Pigeon calls, and converts all the top-level objects used for params and returns to Pigeon objects. However, because of the significant object graph, in order to somewhat limit the scope of this PR I made a cut at that layer in the object graph, with nested objects still using the existing JSON serialization. In a follow-up PR, those will be converted to typed Pigeon objects as well, completing the transition.

Unfortunately a significant amount of JSON code can't be removed yet even though it's now unused by the plugin, because it's part of the API of the public wrappers, so clients may be using it. Once all the JSON code is unused, we could @Deprecated all of it, and then could do a follow-up breaking change later to remove it.

Most of https://github.com/flutter/flutter/issues/117910

Pre-launch Checklist

• [x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
• [x] I read the Tree Hygiene wiki page, which explains my responsibilities.
• [x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• [x] I signed the CLA.
• [x] The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• [x] I linked to at least one issue that this PR fixes in the description above.
• [x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• [x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• [x] I updated/added relevant documentation (doc comments with ///).
• [x] I added new tests to check the change I am making, or this PR is test-exempt.
• [x] All existing and new tests are passing.

[stuartmorgan-g]

This should be ready to review. There's a lot of code, but I went ahead and did all the methods in one PR since having a hybrid of manual method channel code and Pigeon code was kind of weird, particularly in tests. Each method is its own commit though, so it's possible to review incrementally, and I could cut it up if preferred. (It might be useful to look at one incremental commit to see the pattern, and then review in bulk after that?)

@reidbaker If you could give this a manual sanity test, that would be great, since I don't have a setup to be able to do actual end-to-end tests.