Add a general strategy to deal with defaults interactions like the hover interaction on legend items

[emmacunningham]

Is your feature request related to a problem? Please describe.
Interactions with elements in the charts currently may have effects internal to the chart as well as effects controlled externally by the parent application. An example of this is interactions on hover with the legend items. On hover of a legend item, there is a chart internal effect of highlighting the series elements within the chart and also the values for identifying the series are passed along to a listener which the parent application can define. This issue is for addressing that the developer user may also want to control the chart internal effects in some way.

Describe the solution you'd like
There are a few ways to approach this:

• The user cannot change the internal effect but can toggle if the internal effects happen or not in response to an interaction. So maybe for the example interaction mentioned, there is a boolean prop that can be defined that controls if the default internal effect happens or not.
• The user can override the default internal effect. In the example of the legend item hover, the user could override the internal effect and define their own effect for how the series should look when highlighted (currently the default is to reduce the opacity of the non-highlighted series elements, but maybe the user wants to apply a border).

Describe alternatives you've considered
I wonder if we should think about a way to generalize interactions to reduce some of the boilerplate that is replicated everytime we add an interaction. For example, currently, when implementing an interaction, one must:

• add the action to chart state
• add a function in chart state to set/remove any externally defined listener
• within the action, pass through data to the externally defined listener
• add the action to settings component to make it available for components to call the action

Whichever path we take with the defaults, this will add additional things that will need to be done when adding any interactions, so I'm wondering if we also want to think about tackling this generalizations issue.

Additional context
Originally brought up here from this comment in PR #31.

Kibana Cross Issues
n/a

Checklist

• this request is checked against already exist requests
• every related Kibana issue is listed under Kibana Cross Issues list
• kibana cross issue tag is associated to the issue if any kibana cross issue is present

[markov00]

What about having a small step first, adding the possibility to enable/disable specific interactions first?

• TSVB for example doesn't have the possibility to choose the color from the legend.
• on dashboard you can only change color when in edit mode
• we need a way to disable filterings on specific cases

[markov00]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.