Tree sticky scroll: Support compact sticky nodes

[Tyriar]

Testing #199153

For this dir structure:

We see this:

But that omits likely the most important parts which are a, b, c, d, e. So this is what I expect in this case where the maximum is hit:

I don't think the editor does this either (cc @aiday-mar), but some prior art in the terminal is that it prioritizes the most important parts of the prompt to show. Say you have this prompt:

1
2 <cwd>
3 $ <multi-line
4 command>

Lines will be prioritized by command input first, remaining prompt second and empty lines on either end will be trimmed, resulting in 3 > 4 > 2.

[aiday-mar]

Indeed we do not do that in the editor. I think it's also maybe because generally a code hierarchy is not as deeply nested as the hierarchy in the explorer, so it was not so necessary.

[Tyriar]

Another idea is to compact items when they hit the maximum like breakcrumbs or compact folders in the explorer 🤔

So this:

Could smartly merge as needed:

This would also be handy for the editor to make better use of available horizontal space.

[benibenj]

I've started work on exactly this. Compressing the nodes is a cool solution to this problem, but is a lot of work due to the way compressed trees are implemented. Won't be part of this release.

I also had a prototype which supported showing the last 5 elements instead of the first 5, however, the user experience just wasn't nice when scrolling. Also, other trees such as for example in the GHPRI extension have the first or second node as the most important one.