Implement invoice data type plugin, payment processor plugin

A few notes on this.

Commerce has just introduced a number pattern. The issue was that the order ids are not sequential with no gaps, especially with Commerce Recurring. This is a legal requirement for many invoice numbers.

https://www.drupal.org/node/2730131
https://www.drupal.org/node/3080247

I think this will be used on Commerce receipts and the final purchase pane.

-----

It looks to me like in your code you are only looking at order level adjustments but Commerce allows adjustments at both line level and order level.

I think, if tax is not included in the entered product price, then the tax is included at line level.

Promotions are also handled as adjustments, so they can also be at line level, or on the whole order. Or both.

I think it's possible for tax to be at both, depending on the store locality.

-----

When I started looking at Commerce Xero, I didn't understand enough about how it was working, so I've upgraded an old 7.x Commerce Invoice module. The guts of it are going to be very similar to the invoice code here, so when I have it working, I'll paste that part as a comment. I'd like to be able to switch to Commerce Xero because it's more general.

There are a few big differences:

* No strategies; it's just to send orders as invoices. Some of it's likely to be specific to the client it's for.
* I started using Queue, but switched to Advanced Queue because Commerce Recurring uses Advanced. I don't know their reasoning but I didn't want the end users to have to worry about Queues and Advanced Queues which have separate user interfaces.
* When I'm finished, it's likely to bundle up a few invoices and send them together, to reduce the Xero call count.

-----

Aha about the tax processor! One thing I noticed was the fixed account code of 460 for all order level adjustments, and I was thinking that it needed something to be able to vary the account code, depending on the adjustment (promotion, tax, etc) and the user or buyer; 460 doesn't exist in the Xero Demo chart of accounts. But it makes much more sense if there's a processor for it.

The new processor plugins introduced in this patch specify for their 'types' annotation "commerce_xero_invoice" which is the id of the invoice type plugin. I believe they should specify 'xero_invoice' which is the actual name of the type, specified on the commerce_xero_invoice plugin.

+++ b/src/OrderDataTransformationTrait.php
@@ -0,0 +1,44 @@
+  protected function getDefaultContactValues(OrderInterface $order) {
+    $profile = $order->getBillingProfile();
+    if ($profile->hasField('address')) {

This bit me. Let's not assume that orders always have profiles.

Better
if ($profile && $profile->hasField('address')) {

Fixes #11 and #13

Encoding issues with patch should be fixed here.

Straight reroll.

Better reroll, I missed a use statement.

Fix test fails. Also we should use the Xero Query factory. And also need the user module as a kernel test dependency because of using the user data service for tokens in XeroTokenManager.