Tooltips: Support long labels

[Develer]

What is this feature?

This PR provide tooltip's long labels support.

Which issue(s) does this PR fix?:

Fixes #77247

Special notes for your reviewer:

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[adela-almasan]

Hey, good job on this one! 🎉 While testing I noticed some things that were not covered:

1. Long labels in series list (used in Trend), also needs an overflow hidden + ellipsis
2. In header, if we have a label that's too long, the value is pushed too much to the right and it overlaps with the close button
3. In header, if we have a value that's too long, it overlaps the label

[adela-almasan]

Feedback:
cc @lukasztyrala

1. In some cases the header value gets completely hidden
   

2. The changes we made for header need to be applied for all the components we use in tooltips
   

3. The labels/values seem to be missing the hover functionality when pinned (add tooltip with full value)

[Develer]

@adela-almasan This #2 point happened because it is a custom component. In trend tooltip case it's <SeriesList />.

[adela-almasan]

@Develer SeriesList is one of the tooltips components - currently used in Trend, but will also be used in Timeseries and Candlestick and possibly other places, so we need to cover that one too. We need to apply the changes everywhere we've using labels/values.

[Develer]

@adela-almasan got it, then I'll update that one also 👍🏻

[lukasztyrala]

Let's acknowledge that we are dealing with edge cases here, and rarely will there be a situation where both labels and values are super long. But it can happen. A few things to consider:

1. We should provide reasonable defaults for the things displayed in the header. F.e. for the trend panel, we should render the x label and value.

2. We should consider the label component as an interactive and dynamic element that can adapt to options (f.e. where the ellipsis should happen, do people want to wrap the labels, etc.)

3. The tooltip should be responsive.

2 and 3 from above are a song of future improvements, so for now, we need to introduce some rules for the logic:

4. Displaying the value should always be a priority.

5. There should be a minimum label width (at least three characters displayed), and the ellipsis would be applied to values only in a case like this.

If 4 and 5 are hard to calculate or implement, than we should go back to responsiveness? :-)

[Develer]

Hi all! I have types clashing. The question is about the Trend tooltip. Do we really need SeriesList component? It looks totally replaceable by VizTooltipRow component I implemented here.
I noticed that in SeriesList the label can be label?: React.ReactNode type. Are there any scenarios we have to render ReactNode in a label instead of just a string?
Can we take a look at this part together?

cc @adela-almasan

[adela-almasan]

Hey! Context PR for the React.ReactNode type - probably we'll get the chance to test more with complex cases with timeseries. I think SeriesList looks like a wrapper for VizTooltipRow now, so that should be fine - we can iterate depending on how things evolve.

[adela-almasan]

@Develer I'm ok approving and merging if the approach (value on second row) is the one you and @lukasztyrala have discussed yesterday. I can't say it's my favorite, but we can obviously iterate.