Add support for view/DOM element specification in RootConfig#element #20047

Context

Currently, RootConfig#element only accepts an existing DOM element reference (HTMLElement). Per the decisions in RFC #19864 and RFC #19921, this field should be expanded to also accept:

1. A tag name string (e.g. 'h1', 'article') — the editor creates a new DOM element with that tag.
2. A full element definition object — { name, attributes?, classes?, styles? } describing the element to create, including an alternative flat notation where class and style are passed as strings inside attributes.

Classic Editor special case

ClassicEditor uses config.attachTo for the source/reference DOM element. Its root.element defines the editable root created inside the UI box, so it should only accept a tag name or definition object — not a DOM element reference. An error should be thrown if one is passed.

Definition of Done

• RootConfig#element accepts a tag name string — the editor creates a DOM element with that tag and uses it as the editable root.
• RootConfig#element accepts a full element definition object — { name, attributes?, classes?, styles? }, with the alternative flat notation also supported.
• Backward compatible — HTMLElement reference still works. Omitting element defaults to <div>.
• Works in all root contexts — config.root.element, config.roots.*.element, editor.addRoot(), and MultiRootEditor.createEditable().
• Classic Editor guard — logs a warning if a DOM element reference is passed in root.element and ignores it.
• Integrates with modelElement — works correctly alongside RootConfig#modelElement (e.g. $inlineRoot with an <h1> editable root).
• TypeScript types updated — RootConfig#element typed as HTMLElement | string | ElementDefinition.
• Documented — the new config option variants are described in the API docs with usage examples.
• Automated tests cover all three forms across single-root, multi-root, classic editor, dynamic addRoot(), and createEditable().