Viewfield display is not saved inside paragraphs.

A viewfield subfield stores its display, arguments and items in sibling columns named "__display", "__arguments" and "__items", but the submitted value keys them 'display_id', 'arguments' and 'items_to_display'. The display is written as a side effect of setting the view, and core's Map::setValue() then re-syncs every already-instantiated property object from the values array it is handed, so a sibling missing from that array is reset to NULL. Whether the property object already exists at that moment depends on what else in the request has touched a field item of the same type, so the loss is ordering-dependent. Nothing supplied the two mismatched keys, so saving a paragraph silently dropped the display.

CustomFieldTypeInterface gains two static methods, alongside the existing static schema() and propertyDefinitions(): getExtraPropertyNames() returns the full names of a subfield's extra properties, and extractExtraPropertyValues() maps a nested value onto them. CustomFieldTypeBase derives the names from schema() and returns nothing from the extraction, so existing type plugins need no changes; ViewfieldType is the only type that overrides the extraction.

CustomItem::setValue() now completes the values array generically from whatever each subfield type declares, before handing it to core, and accepts only property names the type actually declares. It no longer knows about any individual type. Plugin classes and their extra property names are resolved once per field definition and held in a WeakMap keyed on the definition object; that narrows the staleness window rather than closing it, but a stale map can only offer extras the name filter then discards, never a wrong stored value.

The CustomFieldViewfield data type moves from Drupal\custom_field\Plugin\DataType to Drupal\custom_field_viewfield\Plugin\DataType, so the parent module no longer carries a type that belongs to the submodule. The plugin ID is unchanged, so stored data and property definitions are unaffected. Its setValue() resolves the type plugin through the plugin definition, so the two write paths share one implementation. Caches must be rebuilt after updating.

The overlapping paragraph tests are consolidated into one Functional and one FunctionalJavascript ParagraphsIntegrationTest sharing a single setup trait, replacing five test files and the custom_field_paragraphs_test module. Together they cover the extra properties of every sibling-writing subfield type through a real paragraph form, including the media library modal and the viewfield AJAX display options.

Setting a field item more than once from code with nested values still loses extra properties for the other sibling-writing types. That behaviour is not new here and is tracked in [3622588].

Closes #3620797