Expand Accept.js to include Accept.js UI

@tkiehne: There was no reason for them not being included. Likely an oversight. Patch away. Can they be moved to AcceptJsBase.php to reduce duplication?

Unfortunately the forms are defined in the gateway annotation, so it can't be consolidated into the base class.

There is also a question of organization: the subject forms are Drupal\commerce_authnet\PluginForm\AcceptJs\PaymentApproveForm and Drupal\commerce_authnet\PluginForm\AcceptJs\PaymentDeclineForm - While these work just fine for both AcceptJs and AcceptJsUi would we want to create a copy of each in src/PluginForm/AcceptJsUi just to keep things separate and futureproof? Or maybe refactor those to be in src/PluginForm and make them common to both gateways?

I've found one more issue with this patch. When a customer is selecting a payment method during checkout, there is a script for the UI patch that attempts to reload the AcceptJS-UI script after an AJAX action. The script checks for a specific context id set to a presumed default checkout flow, e.g., in commerce_authnet.acceptjs_ui.form.js:

if (context.id == 'commerce-checkout-flow-multistep-default' && document.getElementsByClassName('button AcceptUI').length > 0)

This is all fine and good if you happen to be using this presumed default checkout flow, or if the Authnet payment method is selected by default and the user doesn't select a different payment method, but in our case we have custom checkout flows so this check is never triggered, meaning the AcceptJS-UI script is not reloaded when the user changes the payment method and the "Add payment information" button doesn't have events attached. Clicking the button will reload the screen and display an error. Ironically, since the Authnet payment method is preselected on the reload, the button will work correctly on second press.

Not sure what the exact fix is, but we shouldn't be presuming a fixed checkout flow id here. Perhaps just check that the context id starts with "commerce-checkout-flow-"?

I've re-rolled the patch in #31 against 8.x-1.8 and added code to address #33 & #36. This checks out against my environments, but it would be nice to have additional verification.

Seems like #32 is the only remaining outstanding issue with this patch. What will it take to get this feature on the release roadmap?

I've updated patch #37 in order to fix a bug with this patch.

to reproduce:

1. Head to user/#/payment-methods
2. Create a new payment method with Authorize.net (Accept.js UI)
3. On success, edit this newly created payment method.
4. Regardless of what YEAR you have specified (while adding the payment method), the year on the saved payment method will always show the first item in the select dropdown (in this case: 23).

The old patch overrides Commerce Payment's default expected expiry year storage format i.e. YYYY to YY. so, the payment methods created by Authorize.net (Accept.js UI) gateway will store year in YY format instead of YYYY. This because the Accept.js UI form allows YY for the expiration year, and that value followed in the whole processing of validation and storing to database.

Re-rolled patch #38 against 8.x-1.10. Also added some modifications to the UI js to disable the pane submit form if no payment info has been added to address #32; I've had this feature in my production site for over a month with no issues, but I have a fairly standard checkout flow so caveat emptor if your checkout flow is highly customized. I also added a few coding standards fixes.

Only remaining issue that I can see is that in the new AcceptJsBase class, the createPaymentMethod() method has code to handle CCA logic which calls a method $this->getCcaApiKey() which was left behind in the AcceptJs plugin. This isn't likely an issue wince the AcceptJsUi plugin will not trigger that code, but I figure this ought to be refactored to have the AcceptJs plugin override createPaymentMethod() to add this logic before calling the Base method. But, I don't use the CCA feature and would appreciate some confirmation before taking that step from someone in the know.

Otherwise, I've been using this patch in its various states in a production environment for almost 18 months with no issues - would love to get some RTBC focus here and move this into the main branch.

Re-rolled #39 to apply to 8.x-1.11

Issue in #40 still unresolved