[BUGFIX] Avoid <o:p> tags pasted from MS Word into CKEditor5

With #99738 the option to allow all classes has been reenabled,
which implicitly caused all custom html elements to be allowed:

```
    htmlSupport:
      allow:
        - { classes: true, attributes: { pattern: 'data-.+' } }
```

The rule matched to any HTML element available in the CKEditor5 General
HTML Support (GHS) schema definition, including the pseudo element
`'$customElement'` that acts as placeholder for custom elements,
because the omitted `name` matcher implicitly acted like a match-all
(`.*`) pattern.

This became an issue, since `@ckeditor/ckeditor5-paste-from-office`
relies on the fact, that the pasted HTML is sanitized by GHS.
Namespaced tags like `<o:p>` (which the desktop version of microsoft
office likes to include when using copy&paste) where now allowed.

To account for this behavior we change two things:

1) We drop the default allow-list configuration that was added in
   v12.4.7, since the negative side effects outweighed the benefits:
   * All HTML Tags where implicitly allowed, which allowed any tags,
     even custom elements to be inserted via copy&paste or via source
     editor
   * All classes were enabled, thus custom Microsoft office classes
     started to pollute the HTML sources.
   * The configuration could not be removed/changed by an integrator
     since htmlSuppot.allow is an array and was therefore only appended,
     but never overwritten by custom RTE configurations

  We considered to switch to a name pattern like `[a-z]+` in our default
  configuration but decided against that because that'd still allow all
  other official HTML elements which is not good default, given that it
  can't be changed as described above.

2) We now restrict migrated CKEditor v4 (extra)allowedContent
   (e.g. `extraAllowedContent: *[*](*){*}`) match-all-elements
   directives (first asterisk in the example) to plain selectors in
   order to exclude custom or namespaced elements like `<o:p>`.
   We therefore migrate to a matcher pattern `[a-z]+` in order for the
   virtual custom-element entry `'$customElement'` to become a no-match.

Integrators are actually expected to define the set of allowed classes
with the CKEditor5 `style.definitions[]` configuration array.

Releases: main, 12.4
Resolves: #102507
Resolves: #102522
Related: #99738
Change-Id: I904f906b7cbbdf5d5f1b3ff23d2b1c62abbcf174
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81995


Tested-by: Benjamin Franzke <ben@bnf.dev>
Tested-by: core-ci <typo3@b13.com>
Reviewed-by: Benjamin Franzke <ben@bnf.dev>