[in_app_purchase] Rename iOS implementation to _storekit

[stuartmorgan-g]

Renames the iOS implementation package to in_app_purchase_storekit, and renames it types and files accordingly, to allow for adding a symlink-based macOS implementation to this package in the future.

Temporarily marks in_app_purchase as unpublishable so that this can be a move, rather than a copy-and-delete-later, which makes for difficult reviews and destroys git blame.

Part of flutter/flutter#86076
Supports flutter/flutter#84391

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.

[cyanglaz]

LGTM

[mvanbeusekom]

Shouldn't we also mark the in_app_purchase_store_kit package as unpublishable so it gives us a little bit of time to include breaking changes for issue flutter/flutter#82795?

Reason is that we are now recreating the CHANGELOG for the in_app_purchase_store_kit package which gives us the opportunity to also include the breaking change for issue flutter/flutter#82795.

[stuartmorgan-g]

It doesn't matter if we publish it first. The reason we don't generally like to make breaking changes is because it's disruptive to packages and apps that depend on the package, not because they are inherently a problem. In this case, it's a package that nobody will have any reason to use directly right now, so there won't be any disruption from the breaking change.

(If one or two people find it before then and decide to start using it directly for some strange reason, they can update to 0.3.0 in a few days.)

[mvanbeusekom]

LGTM. Thank you for explaining my question.