Generilize scrolling and support it in the infrastructure

[mum4k]

Idea proposed by @slok in #164:

Would be nice to mark as scrollable (vertical) any element on the terminal, this is widgets or containers (example a row). I don't know how it would be designed and/or implemented, but I will try to explain:

In the end would be nice to get the same user experience as if you were on a web page, this is, mark a max height on the containers of the grid and if the widgets/containers inside this "scrollable" container are bigger (height) than that, the container would activate the scroll, setting a scroll visualization (could be optional) and giving the user the ability to scroll all the visual stuff inside this container (multiple containers and widgets).

With this, we could gain the ability to create terminal visualizations that aren't limited vertically by the terminal size.

[mum4k]

Initial thoughts - this might require updates to the canvas. Widgets could specify (or receive) just the width of the canvas, the height becomes "unlimited". Widgets would draw all the content they want to and the canvas would throw away anything that isn't visible.

The scrolling gets more interesting when enabled on containers that contain other containers. I.e. how will the splitting work, we will probably need to set some "max height" for the container to keep splitting.

Another interesting case is scrollable containers that contain other scrollable containers.

[dyc3]

I don't think it should just be limited to vertical scrolling, because horizontal scrolling would be nice to have for graphs.

[mum4k]

That is a good point @dyc3, thank you. If we implement this we should allow scrolling in both planes.

[dyc3]

I think widgets should still receive the width and height of the canvas, except call it a viewport instead, and also provide an x/y offset. This way, widgets would still be in charge of what gets drawn where, and we don't have to worry about really wide or really tall widgets using a lot of memory for their cell buffers.

[mum4k]

Very good points, this would give the control completely to widgets. They would be able to choose if they want to potentially utilise more space than is allocated to them in the container. I also like the obvious memory usage optimisation as you have suggested.

The above approach is applicable when we enable scrolling on a single container that directly contains a widget. What might be worth discussing is how to approach a case where scrolling is enabled on a container that contains further containers. Say an entire half of a screen. But we might as well decide that these are two different features and only one of them is worth addressing.