WIP Event Cart convert to use standard payment forms

[mattwire]

Overview

Convert the event cart to use standard payment forms and supported interfaces. Builds on #17339

Before

Very old, unsupported code. Only a single payment processor supported and some don't work (eg. Stripe). Lot's of custom code to create contribution/participants/lineitems and payment made before contribution created.

After

Checkout:

(The pay now button is a sneak-preview of the upcoming google/apple/payment request support in stripe).

Settings:

(translation seems to have got stuck for the first setting despite setting to English!).

Technical Details

This is a major refactor of the event cart checkout following it's move to an extension. We switch to using standard billingblock functionality and support an independent set of payment processors via settings. (Previously this was guessed from the events in the cart and only one processor could be used).
This switches event cart to use Order API + payment propertybag making this probably some of the most up to date code in CiviCRM!

Comments

@eileenmcnaughton @artfulrobot This is still a work in progress because I've not gone through and verified that receipting is working properly (and may switch to Payment.sendconfirmation for this). But you'll be pleased to see it uses Order API to create the contribution, participants and lineitems. And then uses payment propertybag before calling doPayment.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

Closing this as it now needs to be the basis for smaller reviewable PRs to take this forwards (which it can do without being in the review queue) - note I think we should keep anything to do with the property bag out of any work on this. We've got quite a bit of work to do to ensure we have a shared vision on that & I'd rather than wasn't a blocker on this because I'd rather not think about propertyBag again for a while