Update import paths for CKEditor 5 v48

The ckeditor documentation https://ckeditor.com/docs/ckeditor5/latest/updating/nim-migration/migrat... is a little unclear about whether the icons are available in the ckeditor package (probably not because I think they moved icons out of the main package a couple versions ago?).

Separately, I wonder if it's a good idea to delete the CI eslint cache file periodically, in case some upstream changes create JS linting issues like we saw here.

Believe I experienced this when I was updating ckeditor5_dev and other ckeditor contrib modules lots of fun (being sarcastic)

Applied the MR and did testing on standard profile trying out all the ckeditor buttons from core, specifically the media embed. All seems to be working as expected. I cleared cache several times too to make sure it took.

Assuming this will be a D12 only?

Assuming this will be a D12 only?

Yes.

Am I right in thinking this is related to this part of webpack.config.js?

        // Map all ckeditor5 imports to the CKEDITOR UMD global.
        if (request === 'ckeditor5' || request.startsWith('ckeditor5/')) {
          return callback(null, 'CKEDITOR');
        }
        // Map @ckeditor/* package imports to the CKEDITOR UMD global.
        if (request.startsWith('@ckeditor/')) {
          return callback(null, 'CKEDITOR');
        }

Should we trigger a deprecation for the request.startsWith('ckeditor5/') case? Or if this file is only used by core can we remove that case entirely?

I tried commenting out that section (so that it's externals: []) in webpack.config.js while on main, and I got errors running yarn build.

If switch to the MR branch with those if statements deleted, yarn build completes successfully.

As a spot check, I then ran the FJ CKEditor5AllowedTagsTest, but I hitting an additional test failure that does not occur on main. It's strange, though, because when I look at the browser output that is associated with the failure, I get the following, which I can't imagine is related:

Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "router.route_provider", path: "options_request_listener -> router.route_provider -> maintenance_mode_subscriber -> url_generator". in Drupal\Component\DependencyInjection\Container->get() (line 143 of core/lib/Drupal/Component/DependencyInjection/Container.php).

Assuming that error is either unrelated or something specific to my local, I think that section can be deleted if contrib/custom does not use core's webpack.config.sj.

What if you just comment out

if (request.startsWith('@ckeditor/')) {
return callback(null, 'CKEDITOR');
}

?

I tried #11 and things seem to build fine, there a full proof way to show it?

Tested `yarn build:ckeditor5` on this MR branch locally in two scenarios — with the existing webpack.config.js externals kept as-is, and with the `ckeditor5/` startsWith and `@ckeditor/` blocks removed (as discussed in #9–#12). Both produce identical output, all 5 plugins compiling successfully:

```
webpack 5.102.1 compiled successfully in ~285 ms (drupalEmphasis)
webpack 5.102.1 compiled successfully in ~343 ms (drupalEntityLinkSuggestions)
webpack 5.102.1 compiled successfully in ~356 ms (drupalHtmlEngine)
webpack 5.102.1 compiled successfully in ~484 ms (drupalImage)
webpack 5.102.1 compiled successfully in ~514 ms (drupalMedia)
```

The `ckeditor5/src/*` and `@ckeditor/*` externals are now dead code — core no longer uses those import paths after this MR. The webpack.config.js cleanup can be done here or as a follow-up; either way it does not block RTBC of the import path updates themselves.

Also ran FunctionalJavascript tests locally (`CKEditor5ToolbarTest`, `CKEditor5DialogTest`, `CKEditor5ReadOnlyModeTest`, `MediaPreviewTest`, `ImageTestProviderTest`) and `CKEditor5PluginManagerTest` — all pass.

Ran into this again by accident with eslint, which is currently reporting 45 errors on main, opened #3607174: Fix CKEditor eslint import errors before @godotislate pointed out that is a duplicate of this.

Let's defer tidying up webpack.config.js for another day.

Committed and pushed fd41a57a4e9 to main. Thanks!