Hardening against corrupted formatter config (prevents fatals/TypeError)

Problem/Motivation

Hardening: guard getFormatterType() callsites + normalize field_types to array

If a formatter config entity exists with an unknown/missing type (or partially imported/broken config), several call sites assume getFormatterType() always returns a valid plugin instance. In reality it can return FALSE, and that can produce fatals (calling methods on FALSE) during

Additionally, the derivative plugin definition should guarantee field_types is always an array. If it becomes NULL, Drupal core field formatter selection logic can throw a TypeError.

Affected areas (examples)

• Deriver should ensure field_types is always an array: CustomFormatters.php
• Form save should not blindly call submitForm() on a missing formatter type: FormatterForm.php
• Field formatter rendering should handle missing entity/type gracefully: CustomFormatters.php
• Entity lifecycle methods should guard plugin calls and normalize field_types: Formatter.php

Proposed resolution

• Normalize field_types to an array in the deriver (CustomFormatters.php).
• Guard getFormatterType() before calling plugin methods in:
  • src/Entity/Formatter.php (preSave/postLoad/calculateDependencies)
  • FormatterForm.php (save)
  • CustomFormatters.php (rendering)

• In the deriver, normalize field_types:
  • if it’s NULL → []
  • if it’s scalar → [$field_types]
• Guard all getFormatterType()->… callsites:
  • assign to $formatter_type = $entity->getFormatterType();
  • only call methods if $formatter_type is truthy
• In entity methods, avoid using dynamic properties (PHP 8.2+); read/write via $this->get('field_types') and $this->set('field_types', $normalized).

This will prevent hard failures and keeps Drupal UI usable even when configuration is temporarily inconsistent.