[pay_ios] Add support for PKPaymentButtonType.continue (iOS 15+)

[KristijanMitrik]

Is your feature request related to a problem? Please describe.

The ApplePayButtonType enum in pay_ios is missing the .continue case, even though Apple added PKPaymentButtonType.continue in iOS 15. This is the recommended button when the user is enrolling/tokenizing a card for future use rather than completing an immediate purchase (e.g. saving a card on file, setting up a wallet/account for varied future charges).

Without .continue, developers building card-on-file or "add payment method" flows are forced to pick a button whose verb is misleading — buy, checkout, subscribe, etc. all imply something the user isn't actually doing at that step. The only honest fallback today is .plain, which drops the verb entirely.

Describe the solution you'd like

Expose PKPaymentButtonType.continue through the ApplePayButtonType enum. Since continue is a reserved keyword in Dart, the case would need a trailing underscore (or similar):

​dart enum ApplePayButtonType { plain, buy, setUp, inStore, donate, checkout, book, subscribe, reload, addMoney, topUp, order, rent, support, contribute, tip, continue_, // new } ​

On the Swift side, map the new value to PKPaymentButtonType.continue behind an #available(iOS 15.0, *) guard, falling back to .plain on older OS versions:

​swift case "continue": if #available(iOS 15.0, *) { return .continue } return .plain ​

The string sent across the platform channel would be "continue", with the Dart enum case named continue_ purely to avoid the keyword clash.

Describe alternatives you've considered

1. Using ApplePayButtonType.plain — works, but loses the descriptive call-to-action Apple designed for this exact flow.
2. Using ApplePayButtonType.subscribe — only honest when the downstream use is genuinely a fixed subscription with PKRecurringPaymentRequest. Misleading for general card-on-file enrollment.
3. Rolling a custom UiKitView wrapping PKPaymentButton directly — works around the gap but duplicates UI plumbing that pay_ios already provides for every other button type. Not a sustainable long-term answer.

Additional context

• Apple docs: https://developer.apple.com/documentation/passkit/pkpaymentbuttontype/continue
• Available on iOS 15.0+ — older OS versions can gracefully fall back to .plain.
• This is the only PKPaymentButtonType case currently missing from pay_ios. After adding it, the enum will be at parity with the native API.
• Happy to open a PR if the maintainers are open to it.