feat(Apple Pay): allow for customization of event updates

[cbarton]

Adds the options.callbacks option which supports the following
callbacks:

• onPaymentMethodSelected
• onShippingContactSelected
• onShippingMethodSelected
• onPaymentAuthorized
  to correspond with the ApplePaySession events.

A callback must return either the Apple Pay update object or a Promise
that resolves with that object.

That update object will be used to complete the ApplePaySession event
to open up the ability to fetch custom taxes on payment method selection,
update shipping costs on shipping contact/method selection and validate
email/phone addresses on authorization.

This does not remove the existing events being emitted but the workflow
should be updated to prefer using onPaymentAuthorized to complete the
purchase instead of async on the token event. The event that is sent
to that callback includes the payment.recurlyToken for use.

This also enhances the token event to include the raw payment event as
the second argument.

const applePay = recurly.ApplePay({ 
  ..., 
  paymentRequest: { requiredShippingContactFields: ['email'] },
  callbacks: {
    onPaymentAuthorized: ({ payment: { recurlyToken, shippingContact: { emailAddress } } }) => {
      if (emailAddress === "test@example.com") return { errors: [new window.ApplePayError(...)] };
    },
  },
});

This also enhances the token event to include the raw payment event as the second argument.

[cbarton]

Another option is to allow the client to pass in the various handlers on initialize and they call the complete function (that we control) to close out:

const applePay = recurly.ApplePay({ 
  callbacks: {
    onPaymentMethodSelected: (event: ApplePayPaymentMethodEvent, 
                              complete: (update: ApplePayPaymentMethodUpdate) => void) => void;
  },
});

We would still support the emitters as well, but this would be the primary way of defining the explicit apple callbacks.

The token event still works fine, though we should think about if we want the paymentAuthorized event to trigger after we receive the token (and emit it as part of the event) so the merchant can process the purchase to be more aligned with the UX of the payment sheet flow.

[coveralls]

Coverage: 92.473% (+0.04%) from 92.437% when pulling 466aaf1 on apple-pay-errors into 31fc194 on master.