Replace TextTruncator by TextTruncatorCss

[MisRob]

Observed behavior

In #8464, where a new text truncator component based on CSS, TextTuncatorCss, was introduced to the codebase as an alternative to JS-based TextTruncator to prevent introducing more performance issues similar to ones reported in #8124, it seemed that we agreed on replacing TextTruncator by TextTruncatorCss completely. Alternatively, we could discuss creating KTextTruncator from TextTruncatorCss in KDS and migrating to it.

See @indirectlylit's comment

The CSS implementation degrades gracefully on IE11 and otherwise the behaviors are quite similar, so I would support migrating to it entirely rather than maintaining two parallel implementations.

Shorter-term the main question is cost/risk of migration – if either are high, we might want to use both at least until 0.15. Longer-term once things are consolidated, we could even move it to the design system as KTextTruncator.

Note that as @indirectlylit mentioned here we need to be careful about testing the new truncator properly in regards to the following issues to avoid regressions:

• #5468
• #5464
• #4419

Expected behavior

• TextTruncatorCss or KTextTruncator is used everywhere and TextTruncator exists no more

User-facing consequences

Performance improvements