Convert plugins on payment entities to fields

This depends on #2294745: Add a field type for plugins.

Consider adding an interface and a trait for plugins to implements, so they can notify the field of changes and both can be kept in sync with each other.

This patch introduces the field types, but does not yet convert the plugins on payments to fields, nor does it remove current storage code.

onChange() turns out to be *extremely* unreliable for doing anything, as setValue()'s documentation implies the $notify parameter should be FALSE mostly/only when setting a child property's value from a parent. However, TypedDataManager sets $notify to FALSE for no documented reason.

To work around this, I think the only option is to create special data types for each of the field's properties so we can explicitly notify the field (which is the parent) when a property's value changes and as such reliably synchronize all properties.

Seeing as we had to enforce a plugin instance to exist for every field item at all times anyway, it's probably better if the plugin ID and plugin configuration properties are converted to computed properties that are only used for storage, because removes the need for synchronization between the plugin instance and the field item and between the field item's properties.

This is with computed properties. As I should have expected, this won't work without entity storage modifications, because the storage cannot set the values for the computed properties. Just storing a serialized plugin could work, but if we want to be able to query the field, we'll have to store the plugin ID as well.

We can't serialize the entire instance, because it's an instance of a plugin class and plugins by nature are not always available.

Let's try a slightly different approach: three field item properties, of which two proxy calls to the instance that must always exist as the value of the third property. Proxying prevent synchronization problems, while always having an instance (unless the item has no value) keeps the code simple enough to maintain.

Patch is not ready and some tests still fail.

Re-roll.

Many plugins are payment-aware. However, now they no longer have to be set through the payment entity, but can also be set through field API. A simple onChange() on payment entities did not work, because TypedDataManager created field items and sets their values before they are set on the parent. This means the parent (the payment) is notified, wants to grab the instance from the field, but at that point the field is not assigned to the parent yet (one-way reference) and we end up in an infinite loop. Enter PaymentAwarePluginBagItemBase. It doesn't seem to solve all problems yet.

*Puts on his thinking cap*

This needs a modification to FieldItemBase:

diff --git a/core/lib/Drupal/Core/Field/FieldItemBase.php b/core/lib/Drupal/Core/Field/FieldItemBase.php
index b411b88..2ae8f94 100644
--- a/core/lib/Drupal/Core/Field/FieldItemBase.php
+++ b/core/lib/Drupal/Core/Field/FieldItemBase.php
@@ -142,8 +142,8 @@ protected function writePropertyValue($property_name, $value) {
   public function __get($name) {
     // There is either a property object or a plain value - possibly for a
     // not-defined property. If we have a plain value, directly return it.
-    if (isset($this->properties[$name])) {
-      return $this->properties[$name]->getValue();
+    if (array_key_exists($name, $this->getPropertyDefinitions())) {
+      return $this->get($name)->getValue();
     }
     elseif (isset($this->values[$name])) {
       return $this->values[$name];

This includes the fix from #22 added to PluginBagItemBase.