feat(scrollbar): add hover and borderColor style for slider

[slook]

• Added: Use borderColor class style in favour of janky looking shaded/dotted characters for scroller/slider elements.
• Added: hover style for mouse over effect, it is inexpensive since the scrollbar widgets already get mouse events.
• Changed: Use get() in order to tolerate a potential for the non-existance or empty style definition.
• Changed: Use solid line │ ─ UTF-8 characters instead of dotted ┊ ┄ characters which look ugly on some terminals.
• Changed: Use "Black Square" ■ UTF-8 character for horizontal scroller to match the similar thickness of the vertical bar.
• Changed: Use "Full Block" █ UTF-8 character instead of shaded ▓ character because no matching square is available.
• Changed: Use "Plus" + ASCII symbol for scrollers because this is more readable than X against the window edge borders.

Using the solid lines and equal thickness bars gives a much cleaner look and more overall balance to the interface...

The narrower thickness of this horizontal scrollbar is more proportionate to the apprearence of the vertical scrollbar, this makes a large difference to the overall aesthetics balance. It is slightly segmented compared to the full block, but I think it is worth it.

The "jankyness" of the shaded/dotted scrollbar characters is especially noticable in the pyodide sandbox (TryItOnline) where the scrollbar characters do not render well at all, so I am interested to see what this improvement will look like on that platform...

The borderColor style gives the flexibility needed to create a traditional "filled in" scrollbar (by using the same glyphs for both the handle and the slider but with different colors) if desired, such as is done in the screenshot of the Tree on the right.

[ceccopierangiolieugenio]

actually this looks very good:

Just the arrows, we need to check if there are better ones that can be used

[slook]

The filled in bars do look the best, I agree, but it's not suitable for default because using identical characters requires a terminal with color support, whereas the existing thin lines ensures that the sliders are visible even on a monochrome terminal screen. For widget element as fundamental as a scroll bar I think it's important that it is function over form.

Just the arrows, we need to check if there are better ones that can be used

There are some double-width arrows which if used for the vertical bar come out looking the same as the horizontal bar, where the base of the arrows touches the pointers, rather than leaving a gap, at each end...

    hscroll = ('◀','■','■','▶')
    vscroll = ('🭯','█','█','🭭')

... However those arrows are also not suitable to use as default because it's seems hacky having double-width characters for one of the bars but not the other. All the other arrows are odd shapes or even smaller that what's there currently, which is the only sensible choice really.

Another option would be inverting the colors and making square buttons with an arrow cut out, a sort of embossed look, but again that's weird because of the different proportions.

I have also explored the idea of doubling-up the width of the vertical scroll bar to match the fatness of the horizontal bar, and using pairs of opposite triangles for arrows, but the complexity of rendering two rows of glyphs just isn't worth it. Besides, I think the skinny bars look more modern style anyway.

The key thing is that they appear to be about the same thickness, and then the challenge in the future will be to implement half blocks, maybe even quarters, to double/quadruple the working resolution of the vertical bar to match that of the horizontal bar, like this...

5 positions           7 positions
instead of 3:         instead of 4:
▲ ▲ ▲ ▲ ▲             ▲ ▲ ▲ ▲ ▲ ▲ ▲
█ ▄ │ │ │             █ ▄ │ │ │ │ │
█ █ █ ▄ │             │ ▀ █ ▄ │ │ │
│ ▀ █ █ █             │ │ │ ▀ █ ▄ │
│ │ │ ▀ █             │ │ │ │ │ ▀ █
▼ ▼ ▼ ▼ ▼             ▼ ▼ ▼ ▼ ▼ ▼ ▼

... However this requires either finding half blocks with half ╷ ╵ lines sticking out, or using filled in bars with a background color rather than foreground color blocks (but still have to use foreground color squares in the horizontal otherwise the background spills outside the edges). Either way, the horizontals and verticals are going to need separate treatments.