Editor module fails to track usage of files embedded in non-core fields

Problem/Motivation

A module providing a field type can use the TextFormat element type to invoke editor handling. However, doing so will lead to the bug that files embedded vie an editor in the text area will not be registered as used and therefore, if not used elsewhere, by default will be deleted.

This bug occurs for example in the FAQ Field module, see #2744905: Inline images in the answer field are removed during file garbage collection.

The issue arises from the function _editor_get_formatted_text_fields(), which is used to determine whether a given field should be scanned for embedded files. The function uses a hard-coded list of field types:

  // Only return formatted text fields.
  return array_keys(array_filter($field_definitions, function (FieldDefinitionInterface $definition) {
    return in_array($definition->getType(), array('text', 'text_long', 'text_with_summary'), TRUE);
  }));

Proposed resolution

Criteria to consider for a solution

Has to support the three existing core field types, 'text', 'text_long', 'text_with_summary'.
Supported field types must have a value property, since the processing in _editor_get_file_uuids_by_field(), which calls _editor_get_formatted_text_fields(), consults $field_item->value.

Proposed solution

Examine field types and return those that are a subclass of TextItemBase. The current patch takes this approach.

Advantages:

Reduces the hard-coding/special-casing of core field types.
Maintains support for the three existing core field types.
Encourages other modules providing formatted text field types to extend the existing core ones or a common base, rather than adopting custom solutions.
Avoids significant API changes.

Disadvantages:

May be difficult for module developers to discover. Would need documentation.
Doesn't fully remove special-casing of core field types, since this snippet remains:
```
      if ($field_item->getFieldDefinition()->getType() == 'text_with_summary') {
        $text .= $field_item->summary;
      }
```
However, that could be separately addressed (for example, by determining if the given field type plugin has a 'summary' property instead of using a hard-coded field type ID).

Other options

Invoke an alter hook to allow other modules to register their field types as providing formatted text fields. However, this could return non-valid field types (ones that don't have a value property).
Add a field type property that allows plugins to designate their field type as providing a formatted text field.