Widget scroll

[GuillaumeLescure]

Description:

The container.Scroll has a performance pitfall because it render every widgets even thoses that are not displayed.
The widget.Scroll solves that issue.

This PR is in WIP.
This is a prototype that demonstrates the design, I intend to improve it it with any given help.
There is still some issues with embedded containers (I can work on it) and the performances aren't as good as hoped (some help is welcome here).
It's my first PR for Fyne so I'm pretty sure there is still some work to do on my PR and it souldn't be pushed as it is.

Fixes #5914

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

Where applicable:

• Public APIs match existing style and have Since: line.
• Check for binary size increases when importing new modules.

[Jacalz]

Thanks for the PR. The scroller that we are using is already a widget so would it not make sense to try and improve the performance of that instead of adding a new scrolling widget?

FYI: I would recommend making this "draft" while it is WIP.

[andydotxyz]

I don't really understand what this is doing - but it seems to have some assumptions that don't hold:

a) A scroll can never change it's available directions
b) Apps don't need to control scroll position (i.e. messaging apps that always default to the bottom of the scroll)
c) a Container only has 1 root item

It is unclear why you are treating a container as a special case.

If you can explain the /how/ of the new optimised scroll that doesnt have to know child sizes then it might help us to offer suggestions.

There is still some issues with embedded containers (I can work on it) and the performances aren't as good as hoped (some help is welcome here).

As mentioned above please explain what the strategy is otherwise it's hard to say why performance is not what you'd expect.
Scrolling is hard and most times the only way to know the size of a child is to ask it (which requires renderer initiation).