add support multi-typed entities

Problem/Motivation

json_ld_schema_ui currently emits the @type key of every generated JSON-LD graph node as a single scalar string, taken verbatim from
the schema_type property on each schema_content_settings config entity.

Schema.org explicitly permits, and in some cases recommends, multi-typed entities — a single node that belongs to two (or more) classes at once. The canonical
form is a JSON array:

{
    "@context": "http://schema.org/",
    "@type": ["Organization", "ProfessionalService"],
    "name": "Acme Law Firm"
  }

See:

• https://schema.org/docs/datamodel.html (section "Multiple types")
• https://json-ld.org/spec/latest/json-ld/#specifying-the-type

Common real-world cases:

• Organization + ProfessionalService / LocalBusiness
• Article + NewsArticle / BlogPosting
• Product + IndividualProduct
• Person + Patient (medical sites)

Today the module forces site builders to pick exactly one class, which either loses information or forces a workaround (manually hand-writing JSON-LD alongside
the module's output).

Proposed resolution

Mirror the precedent set in #3462176 (1.0.6, Jan 2026), which added
allow_multiple for per-property comma-separated arrays, and extend the same convention to the top-level @type:

• Keep schema_type as type: string in config schema — backwards compatible, no config migration needed.
• At render time in JsonLdProcessed::getValue(), split the stored schema_type on ,, trim each segment, and:
  • if exactly one segment → emit "@type": "Foo" (current behaviour, unchanged),
  • if two or more segments → emit "@type": ["Foo", "Bar"].
• Keep the override-lookup key ($schema_overrides[$schema_type_raw]) pointed at the raw stored string so existing overrides continue to
  resolve.
• Update the admin form help text to document the comma-separated syntax.
• Update README with a "Multi-typed entities" section.

Remaining tasks

• Extend JsonLdProcessed::getValue() with the split/trim/flatten logic
• Update admin form (EntitySchemaConfigurationForm) help text to describe comma-separated input
• Add functional test coverage for: multi-type rendering, single-type regression, trailing-comma edge case
• README "Multi-typed entities" section
• MR against 1.0.x

User interface changes

Minimal. The schema-type picker on the add-schema form continues to accept a single selection. The per-schema form gains a help-text note explaining that the
stored type field accepts a comma-separated list for multi-typed entities. No migration and no config schema change.

API changes

None. ContentSchemaSettings::getSchemaType() keeps returning the raw string. Optionally a new getSchemaTypes(): array helper can be
added for consumers that want the parsed list without duplicating the split logic.

Data model changes

None. Existing single-type configs keep emitting a scalar @type; only configs whose schema_type contains a , produce an
array at render time.

Backwards compatibility

Fully backwards compatible. Every existing schema_content_settings config entity whose schema_type does not contain a comma renders
identically to 1.0.6.

Related issues

• #3462176 introduced the allow_multiple convention this issue
  mirrors.