[META] Unify entity fields and field API

alex, berdir and yched and me had a hang-out discussing this quite a bit. Here's the google doc we used to write down some notes: https://docs.google.com/document/d/1nXwKtFYfKLrCLy4pkxzoxfYteSkIIUF1QI0w...

I try to shortly summarize it here:

Field types as plugins

• We already have field item classes and field classes for each field type for the entity field API, i.e. classes for $node->body and $node->body[0].
• For DX it would be good if developers would have to expose only one class in order to provide a new field type.
• Entity field / field item classes could be extended with a configurable field interface holding necessary additions needed by the field API, e.g. like getSchema(), insert(), update() "hook", ...
• Problem are methods/callbacks for multiple handling like load() and prepare_view(). One possible idea is to off-load them to an optional multiple handler as most field types don't require them anyway.

Improve formatters and widgets to make them usable with all fields

• Formatters and widgets depend on field API $field and $instance data structures, so currently we cannot use them with entity fields.
• We don't want to require config entities for base entity fields defined by the entity type (node title, node language, node nid, ..) as those are critical for the entity type to work, so it should not depend on any CMI files to be there and everything be in sync. (Not mentioning field configs are entities as well ...)
• We discussed multiple options for making formatters and widgets work independently from field instances and $field. We figured out that formatters and widgets mostly rely on instance settings and field settings plus some foundational field information. After discussing separate proxy objects, mappings etc. we figured that a merged representation of the field and instance object would cut it. Fortunately, we could serve that via the entity field object $items as we can merge settings in its getDefinition() method, e.g. see this code snippet:
  

  class Formatter {
  
    function render (FieldInterface $items) {
  
       // getDefinition() of a configurable field would merge instance and field settings,
       // while an entity field would just have to take care to provide the necessary settings.
       $definition = $items->getDefinition();
       $default_value = $items->getDefaultValue();
       $settings = $definition[‘settings’];
       $cardinality = $definition[‘cardinalty’];
    }
  
   function settingsForm($definition) {
  
   }
  }
  

  That way, an entity field that wants to make use of a field formatter or widget would just have to make sure it has the necessary settings in place also. Formatters and widgets still explicitly state which field types they support.

Move field storage to entity storage

See #1497374-37: Switch from Field-based storage to Entity-based storage

Updated issue summary.