Add settings summary to the behavior plugins

Discussed with @Berdir, it is better to implement a settingsSummary() in the interface, config schema won't be enough.
Adding patch with settingsSummary implemented and tested with the test plugins.

1. +++ b/tests/modules/paragraphs_test/src/Plugin/paragraphs/Behavior/TestBoldTextBehavior.php
   @@ -68,4 +68,14 @@ class TestBoldTextBehavior extends ParagraphsBehaviorBase {
   +    $settings = [
   +      'Style' => $bold_setting ? 'Bold' : 'None'
   +    ];
   

   key doesn't matter, that is not displayed. But the summary should be properly translated string, e.g. $bold_setting ? $this->t('Bold: Yes') : $this->t('Bold: No').

2. +++ b/tests/modules/paragraphs_test/src/Plugin/paragraphs/Behavior/TestTextColorBehavior.php
   @@ -99,4 +99,14 @@ class TestTextColorBehavior extends ParagraphsBehaviorBase {
   +  public function settingsSummary(Paragraph $paragraph) {
   +    $text_color = $paragraph->getBehaviorSetting($this->pluginId, 'text_color');
   +    $settings = [
   +      'Text color' => $text_color
   +    ];
   

   And here it would be $this->t('Text color: @color', ['@color' => $text_color])

1. +++ b/tests/modules/paragraphs_test/src/Plugin/paragraphs/Behavior/TestBoldTextBehavior.php
   @@ -68,4 +68,14 @@ class TestBoldTextBehavior extends ParagraphsBehaviorBase {
   +    $settings = [
   +      'Style' => $bold_setting ? 'Bold' : 'None'
   +    ];
   

   key doesn't matter, that is not displayed. But the summary should be properly translated string, e.g. $bold_setting ? $this->t('Bold: Yes') : $this->t('Bold: No').

2. +++ b/tests/modules/paragraphs_test/src/Plugin/paragraphs/Behavior/TestTextColorBehavior.php
   @@ -99,4 +99,14 @@ class TestTextColorBehavior extends ParagraphsBehaviorBase {
   +  public function settingsSummary(Paragraph $paragraph) {
   +    $text_color = $paragraph->getBehaviorSetting($this->pluginId, 'text_color');
   +    $settings = [
   +      'Text color' => $text_color
   +    ];
   

   And here it would be $this->t('Text color: @color', ['@color' => $text_color])

Did the changes from #6 comment.

Updated with last commit

1. +++ b/src/ParagraphsBehaviorInterface.php
   @@ -103,4 +103,15 @@ interface ParagraphsBehaviorInterface extends PluginFormInterface, ConfigurableP
   +   * @return array
   +   *   The plugin settings.
   +   */
   +  public function settingsSummary(Paragraph $paragraph);
   

   string[]

   We don't return settings, we return a summary that describes the settings.

2. +++ b/tests/modules/paragraphs_test/src/Plugin/paragraphs/Behavior/TestBoldTextBehavior.php
   @@ -68,4 +68,14 @@ class TestBoldTextBehavior extends ParagraphsBehaviorBase {
   +    $settings = [
   ...
   +    ];
   +    return $settings;
   

   I'd just write this as return [$bold_setting ? $this->t('Bold: Yes') : $this->t('Bold: No')];

   no need for a variable or array keys.

1. Changed array -> string[]
2. Changed return array in the plugins.
3. Fixed test

Looks good to me now.

Worth noting that committing this will break paragraphs_collection as there is no default implementation.

Since not all behaviors will have settings, we shouldn't make this required, lets add an empty default implementation that returns an empty array.

Added default settingsSummary.

Ok. We're not actually using this yet but the diff issue will be using it.

+++ b/src/ParagraphsBehaviorInterface.php
@@ -103,4 +103,15 @@ interface ParagraphsBehaviorInterface extends PluginFormInterface, ConfigurableP
+   * Provides a summary of the plugin settings of a paragraph.

I'm missing a formal definition about what a summary should be. For instance:
The summary could skip indicating default values, because they are assumed, thus not worth getting space in the summary.
The summary could define being verbose, the rule would be to always output every relevant / configurable setting with its label and value.

For diff reasons, the second might make more sense.
For display reasons, the first could make more sense.
What happens for more complex settings such as a nested structure? What would be the expected presentation in the string?
Output as in summary completely depends the use cases about how to display.
Some cases also would demand for a more structural approach with a label + value each.

With these questions, i just want to avoid that we commit ourself to an API that we later would want to change.

field formatters also don't have much more than that: "* Returns a short summary for the current formatter settings.".

That said, of a paragraph" is of course bogus, I'd use above, simply replace formatter with behavior.

IMHO, the structure is OK, I wouldn't go for a more formal structure, this would also allow to put multiple yes/no options on one line and stuff like that, how detailed we want it to be is something we can still change and is something we need to decide per-plugin anyway.

OK great, let's get this in and use it for the diff change indication, so we can gain experience with our plugins.

Changed method docs.

Committed. :-)