fix(scrollbar): show in small viewport

[slook]

• Fixed: Allow drawing of smallest possible scrollbar size by avoiding a division by zero of asciiDrawingSize on slider drag.
• Changed: Swap the order of drawing arrows to prioritize the up/left arrow over down/right for a 1px bar.
• Changed: Avoid one of the superfluous recursive calls while processing during setting geometry.
• Removed: Avoid calling an update during init by not setting the maximum dimension which isn't used.

If the viewport dimention is only 1 character in either dimension then the viewport's content is preferred:

In future it might be desired to draw the slider element (or a diamond/lozenge?) instead of one arrow in a 1 character bar, but for now this is better than randomly disappearing when the viewport size becomes smaller than 4 characters.

There is some unnecessary looping going on during resize operations, but scrollbars that are too small isn't a directly related to that (there was a divide by zero crash before).

In future it should also be considered how to avoid setting range parameters and so on whilst a resize operation is currently in progress, as ideally those values only need setting if, the scrollbar is visible; it is needed, and; not until after mouse release.

This PR doesn't fix the problem with a scrollbar not hiding itself when the only reason for it being visible is due to the visibility of the scrollbar for the other dimension (that shall require yet other recursive calculation to make an accurate decision).

[ceccopierangiolieugenio]

I need to doublecheck it,
I remember doing many trickery to avoid the edge case where the auto scrollbar was changing the size of the internal widget triggering the second scrollbar to show and starting some kind of loop of scrollbars displaying and disappearing.

[slook]

I think you have avoided that problem by making the visibility decisions based on the viewFullAreaSize measurement (as if no scroll bars were visible). Hence, the trickery you did before means that the minimum size enforcement is no longer required.

Albeit something is still off-by-one somewhere (preventing a scrollbar from disappearing when no longer needed), but whatever that slight miscalculation is doesn't seem to cause any kind of negative looping behavior that I can see.