CKEditorPluginManager::getCssFiles() and CKEditorPluginCssInterface::getCssFiles() should be library-aware and override-aware

Problem/Motivation

@effulgentsia in #2994696-198: Render embedded media items in CKEditor.2:

+++ b/core/modules/media/src/Plugin/CKEditorPlugin/DrupalMedia.php
@@ -0,0 +1,126 @@
+      $this->moduleExtensionList->getPath('media') . '/css/filter.media_embed.css',
+      $this->moduleExtensionList->getPath('system') . '/css/components/hidden.module.css',

If a module or theme is overriding these, I'm assuming we want those overrides in the editor too? In which case, we should get these values from the library info.

@effulgentsia in #2994696-200: Render embedded media items in CKEditor:

In which case, we should get these values from the library info.

To clarify, here's what I mean...

Inject the 'library.discovery' service into DrupalMedia. Then in getCssFiles(), instead of $this->moduleExtensionList->getPath('system') . '/css/components/hidden.module.css', do this...

$library_definition = $this->libraryDiscovery->getLibraryByName('system', 'base');
// Find the item in $library_definition['css'] that contains 'hidden.module.css' in its 'data'. Return that item's 'data'.

That's for 'hidden.module.css', because we don't want the rest of system/base.

But for filter.media_embed.css, I think we should return all of the items that get returned in $this->libraryDiscovery->getLibraryByName('media', 'filter.media_embed')['css'].

@Wim Leers' response to that:
Interesting point. But … \Drupal\ckeditor\Plugin\CKEditorPlugin\DrupalImageCaption::getCssFiles() and \Drupal\ckeditor\Plugin\CKEditorPlugin\Language::getCssFiles() are also not yet doing that. How about we create a follow-up issue to fix all of those at the same time? Right now, this is just following the existing pattern in Drupal core. Besides, this arguably should be handled in the caller of a plugin's getCssFiles(): \Drupal\ckeditor\CKEditorPluginManager::getCssFiles(). Then we don't burden each CKEditor plugin with this. Would you be okay with that? EDIT: #200 is a very helpful clarification! I still believe we should fix this one abstraction level higher. But … perhaps that's just not possible in the abstraction we have: if each plugin is supposed to return CSS files, then the caller (one abstraction level up) can't magically determine which asset libraries they originate from. So … I think that means I agree with you. 😁👍 I think we then do need a follow-up to fix other CKEditor plugins to do this too, as well as update the API docs to recommend this pattern. For CKEditor 5, we should not port this API design flaw in #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD