Allow admin orders to add child variations in 2.0

Might need to look into how programmatic creation of children should be handled. With this patch applied, the children can attempt to be created.

Seeing this error in migrations, due to $parent_variation not being set:
TypeError: Drupal\commerce_vado\EventSubscriber\VadoEventSubscriber::createChildren(): Argument #1 ($parent_variation) must be of type Drupal\commerce_product\Entity\ProductVariationInterface, null given, called in /var/www/html/web/modules/contrib/commerce_vado/src/EventSubscriber/VadoEventSubscriber.php on line 310 in /var/www/html/web/modules/contrib/commerce_vado/src/EventSubscriber/VadoEventSubscriber.php on line 103 #0 /var/www/html/web/modules/contrib/commerce_vado/src/EventSubscriber/VadoEventSubscriber.php(310):

I think something like this might be better:

      if ($order->get('cart')->getValue()[0]['value'] == FALSE) {
        $parent_variation = $order_item->getPurchasedEntity();
        // Create children for non-cart orders only.
        if (!$parent_variation) {
          return;
        }
        $children = $this->createChildren($parent_variation, $order_item, $order);
        return $children;
      }

Ok, moved child creation to a service instead of having it jammed in the event subscriber. The only bit that really deals with this issue is the section from the presave event:

      // Create children for non-cart orders only.
      if ($order->hasField('cart') && !$order->get('cart')->value) {
        $product_variation = $order_item->getPurchasedEntity();
        if (!$product_variation) {
          continue;
        }
        $children = $this->vadoChildManager->createChildren($order, $order_item, $product_variation);
        return $children;
      }

This bit was necessary for making sure the parent wasn't deleted:

    // Ensure that order items are not compared with themselves.
    $order_items = array_filter($order_items, function ($existing_order_item) use ($order_item) {
      return $order_item->id() !== $existing_order_item->id();
    });

So the only thing I think is needed here is to decide what the behavior should be with orders created programmatically. I know I encounter bumps with this patch when migrating, but I had a specific use case were variations were becoming parents in the migration.

We could check for the Order admin form in the request if we wanted to restrict this to admin UI orders.
We could also offer a setting. But I think those could be addressed down the road.

I think a case can be made where you don't want deleting the parent on an admin order to delete the children.