Final pass over the public API prior to creating core merge request

Problem/Motivation

Problems spotted:

1. ✅\Drupal\ckeditor5\Plugin\CKEditor5PluginInterface::getDynamicPluginConfig() does not specify a return type hint
2. ✅\Drupal\ckeditor5\Plugin\CKEditor5PluginInterface::getDynamicPluginConfig()'s docs for the first parameter were not updated in #3215600: Unclear relationship between "plugin_config" in *.ckeditor5.yml and Drupal plugin settings to generate that configuration as they should've been
3. ✅ \Drupal\ckeditor5\Plugin\CKEditor5PluginDefault needs an @see \Drupal\ckeditor5\Annotation\DrupalAspectsOfCKEditor5Plugin::$class
4. ❌ We should make the variable names and patterns used in all the current PHP CKEditor 5 plugin classes consistent, to make it easier to review and to make it easier for plugin developers to look at examples. → #3228920: Improve internal consistency: consistent variable names and return type syntax
5. ❌ Consistently use function foo(): TYPE as return type hint code style, not function foo() : TYPE — per @tim.plunkett, this is the vast majority in Drupal core, even if there is no coding standard yet. → #3228920: Improve internal consistency: consistent variable names and return type syntax
6. ❌ We should probably remove the settingsForm() method from \Drupal\ckeditor5\Plugin\CKEditor5PluginConfigurableInterface and instead make CKEditor5PluginConfigurableInterface also extend \Drupal\Core\Plugin\PluginFormInterface. It's not because CKEditor 4 had that in \Drupal\ckeditor\CKEditorPluginConfigurableInterface that we need to repeat that pattern for CKEditor 5. (That interface was committed in February 2013, and PluginFormInterface was committed in August 2013, which explains this.) → spun off into #3228477: CKEditor5PluginConfigurableInterface should extend PluginFormInterface and ConfigurableInterface instead of adding ::settingsForm().
7. ✅ \Drupal\ckeditor5\Plugin\CKEditor5PluginInterface::getDynamicPluginConfig() receives Editor, this should be EditorInterface. Same for CKEditor5PluginConfigurableInterface::settingsForm().
8. ✅ TextEditorObjectDependentValidatorTrait is a trait with clear responsibility/intent. CKEditor5ConstraintValidatorTrait is not. It forces a particular interface and injects the CKEditor 5 plugin manager. So it should be renamed to PluginManagerDependentValidatorTrait .
9. ✅ Docs in CKEditor5ConstraintValidatorTrait refer to ToolbarItemConstraintValidator — copy/paste leftover.
10. ✅ CKEditor5PluginManager needs an interface
11. ❌ Removing SourceEditor from toolbar did not remove config from editor.editor entity... → I cannot reproduce this.
12. ❌ One thing I did not like from #3228477: CKEditor5PluginConfigurableInterface should extend PluginFormInterface and ConfigurableInterface instead of adding ::settingsForm(): public function getPlugin() on \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getPlugin(). If we must have it, why not just add an optional parameter to ::createInstance()? That's okay to comply with the interface, and there's precedent in core: \Drupal\Core\Plugin\PluginFormFactory::createInstance() does it too. → #3228945: CKEditor 5 plugin instances shenanigans: text editor plugin is statefully coupled + plugin instance methods on manager
13. ✅ CKE5PMI's (CKEditor5PluginManagerInterface) ::getEnabledDefinitions(), ::getEnabledLibraries() and getCKEditorPluginSettings() typehint to Editor instead of EditorInterface
14. ✅ CKE5PMI::getReadableElements() really belongs on HTMLRestrictionsUtilities
15. ✅ CKE5PMI::getWildcardTags(), \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::WILDCARD_ELEMENT_METHODS and \Drupal\ckeditor5\Plugin\CKEditor5PluginManager::getBlockElementList() do too, but are a bit trickier to move
16. ✅ CKE5PMI::getCKEditorPluginSettings is an oddly named method for at least two reason: 1) it says "CKEditor", not "CKEditor5", 2) it returns much more than the plugin settings: it also returns the toolbar configuration and which plugins to load. It was introduced very early in the life of this module: in #3195965: Register CKEditor 5 plugins via YAML definitions instead of class annotations — which was the 4th commit that actually had an issue number associated with it. It was a fine name back then. I think we can stay true to the current name though: just omit the "CKEditor" part in the method name, and move the toolbar pieces out of the plugin manager and into \Drupal\ckeditor5\Plugin\Editor\CKEditor5::getJSSettings(), which is the only place where this method gets called. Then the plugin manager again is doing what it's doing: managing plugins. Nothing else. Also, it should be "config", not "settings", because that's what it's called in the annotation, the YAML, the optional dynamic config method and in https://ckeditor.com/docs/ckeditor5/latest/api/module_editor-classic_cla....
17. ✅ \Drupal\ckeditor5\AdminUi needs to be marked as @internal! As does \Drupal\ckeditor5\HTMLRestrictionsUtilities.
18. ✅ CKE5PMI's ::getToolbarItems(), ::getAdminLibraries(), ::getEnabledLibraries() and ::getEnabledDefinitions() do not have a return type.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes