Issue #3585660: Support multi-typed @type on schema content settings

Schema.org permits a single entity to belong to more than one class (e.g. Organization + ProfessionalService). This adds that capability end-to-end.

Storage: the schema_type property on schema_content_settings remains a string, with a comma as delimiter for the multi-type case. No config migration is required; existing single-type configs are untouched.

Rendering: JsonLdProcessed splits the stored value on comma, trims each segment, drops empties, and emits @type as a JSON array when there is more than one type. Single-type values continue to render as a scalar string. The override lookup key stays pinned to the raw stored string so existing per-property overrides keep resolving.

Config id: ContentSchemaSettings::id() now derives from the first type only, keeping generated config names valid when comma-separated values are stored. Single-type ids are unchanged.

Admin UI: the per-schema configuration form gains a "Schema types" details block showing the primary type read-only and an editable "Additional types" textfield (comma-separated). Each additional label is validated against the loaded schema.org vocabulary via SchemaDataInterface::getSchemaId(); unknown labels produce form errors. On save the stored schema_type is rebuilt from primary + additional.

Tests: a new functional test case covers the multi-type array output, single-type scalar regression, and the trailing-comma edge case. Each case uses a distinct node bundle to avoid the field-storage install/uninstall cycle triggered by deleting the last content schema settings entity for a given entity type.

Docs: README gains a "Multi-typed entities" section with the UI flow and the resulting JSON-LD shape.

Closes #3585660