Implement declarative image style drop-downs

[oleq]

📝 Provide a description of the improvement

config.image.style.groups makes little sense because it has no impact on the model/data/upcast and general logic of the feature. It exists only to create dropdowns in the component factory. 

Instead of using this configuration, we can configure dropdowns declaratively, thus separating the model and view layers.

Related to #1472 (comment).

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[magda-chrzescian]

@oleq @Reinmar This way we won't provide the default dropdown configuration for custom editor implementations (other than builds with predefined toolbars). So the developer won't be able to use toolbar: [ 'imageStyle:wrapText' ].

Also, the image.style.options that we provide also aren't separated from the view layer - it is used for creating the style buttons, so using image.style.groups for creating dropdowns seems consistent in some way.

[oleq]

I guess we can have some pre-defined drop-downs already registered in the component factory, such as 'imageStyle:wrapText' which can be referenced by their name. When the editor initialized, the image style feature will analyze the toolbar config and then:

• populate the component factory using dropdown definitions,
• and use pre-defined dropdowns by name.

---

A random thought: I just realized that to make declarative drop-downs work, they need to be registered in the component factory before the image toolbar is loaded (WidgetToolbarRepository calls ToolbarView#fillFromConfig() and that helper is based on the component factory). And since ImageToolbar is standalone and only required by the top-level editor configuration, this could be a problem (although it kicks in on afterInit so maybe not, this needs to be checked).

[magda-chrzescian]

We discussed this issue with @oleq and we had some concerns about the place where the image.toolbar dropdown definition should be replaced with the name of the component registered in the ComponentFactory. It has to be done at some point because the ComponentFactory#add can handle the registered components' names only and should not be responsible for registering anything. We defined a few options:

• To override the dropdowns definitions with their names directly in the ImageStyleUI - but we don't want to mutate the toolbar config.
• To extract the dropdown name and handle it in the ToolbarView#fillFromConfig method.
• To listen to the WidgetToolbarRepository#register or even ComponentFactory#create from the ImageStyleUI and register the dropdowns and override the declarations in the flow - so the ImageStyleUI wouldn't have to read the image.toolbar.
• To normalize the declarative dropdowns definitions while creating the imageToolbar - which is the solution that we picked, for now, to encapsulate this functionality in the image package only.

We also explored some options of extending this feature to support declarative dropdowns globally. To allow the user to contain buttons from various plugins in a single dropdown, creating the dropdowns could be handled while initing the editor UI. It triggers after all of the plugins are already inited, so all of the buttons should be already registered in the ComponentFactory.

[oleq]

Closed in #9537.