Port support for recurly.Pricing() from D7 to D8

Here's a first pass at porting the D7 recurly.Pricing() related code to D8. With this patch applied the `RecurlyJsSubscribeForm` form will display a summary at the top of what the user is going to purchase. The summary will automatically update when things like quantity change, or when a coupon is added. It also fixes some client side error handling on the form. For example, validating coupon codes.

This provides feature parity with the D7 module's checkout form.

Here's an example of what this looks like (using a non-default theme):

This version uses a better #weight setting for the new fields. When testing the previous version I also had some change in place from another patch and after removing them the weights didn't quite work right.

The tests failure here is because of #3238416: 4.x branch is failing: Class 'Drupal\simpletest\WebTestBase' not found in modules/recurly_hosted/src/Tests/RecurlyHostedWebTest.php.

This patch exposes some issues with the recurlyjs module's use of dependency injection of the recurly client. In https://git.drupalcode.org/project/recurly/-/commit/ad872d19112b1efa9d5d... the calls to recurly_client_initialize() where removed, and the $client was injected into the form controller, but never actually used. This doesn't actually break anything until you add this patch because all of the calls to initialize a Recurly object like new Recurly_Plain($plan_code) or new Recurly_Account() etc. in the recurlyjs module happen after recurly_account_load() is called. And recurly_account_load() initializes the API client with the keys required to connect to Recurly.

When this patch is applied though it adds a new Recurly_Plan($plan_code) gets made prior to any calls to recurly_account_load(). The client hasn't initialized with a set of API keys, the request to get a plan fails.

To fix this, we should be injecting the Recurly_Client object into calls like this new Recurly_Plan($plan_code, $this->recurlyClient). Ensuring both that there's an initialized client. And that it can be mocked for testing.

I've gone ahead and created a merge request with Blake's patch from #6. And then fixed the use of the recurly API client so that it'll work for this patch. As well as the other places it's used in the recurlyjs module.

I added a very basic test the MR which confirms that the Drupal specific JavaScript does what it's supposed to. Namely show/hide elements on the page depending on the response received from Recurly. In order to further test the integration though we would need to have some way to proxy and mock the RecurlyJS API calls. Which ... I'm not sure how to do yet.

The alternative is to setup a Recurly development instance, and run some integration tests against that. Which, is what we're doing for Drupalize.Me. So I do at least have some tests that prove this is working even though they're not currently being run by Drupal CI.

I think we should merge this in as is. Then circle back and look at resolving #3241695: Recurly unauthorized API and #3295143: Recurly singup plan form at validation throwing "undefined" message which both touch some of the same code. And add additional tests at some point that cover the other aspects of the RecurlyJSSubscribe form that are not currently covered here. Like for example the setting to change which address fields are displayed depending your billing requirements.

Thanks @blakehall for the additional review. And yeah, there's a lot of PHPCS issues right now, though I think we can/should deal with those in another issue. #3267917: Fix the issues reported by phpcs. And then work on being diligent about not introducing new standards violations once all the existing ones are resolved.