WIP: Experiments and hacks attempting to implement SwiftUI-like layout flow

[mortenbekditlevsen]

Please don't look at this yet - it's horrible! :-)

Currently I made a lot of types in TokamakCore public in order to perform the layout in the renderer. The layout should actually reside in TokamakCore with only a slim api to the renderer.

The GTK renderer is my current experimentation playground.
Instead of always returning a GtkWidget for the AnyWidget conformance it's now ok to be a 'virtual' (pure layout) widget and not return any actual control.
A 'context' is used to keep a stack of offsets used during layout - as well as a reference to the last actual widget container where all child elements should be added.
The only implementation of the sizing/layout is for Text where the GtkWidget is actually measured to return it's size, as well as _ShapeView whose size doesn't rely on any actual measuring.
Box (a helper type used by HStack and VStack in the GTK renderer) implements an extremely naive version of a layout. It's completely wrong, but shows how the sizing/layout could be tied together.
For the actual algorithm I propose to use the MIT licensed NotSwiftUI sample code from Objc.io. Perhaps only paying members of the Swift Talk video series have access, but I do have access through my work.
This naturally requires Tokamak to include the LICENSE text with copyright notice from objc.io.

I am currently experimenting with Overlay, but I think now is the time to move the size and layout protocol requirements into TokamakCore.

Apologies for the extremely rough/messy state of this draft PR. :-)

[mortenbekditlevsen]

Hi @j-f1 ,
Thanks so much for your work on this PR.
I've unfortunately not had much time to put into this lately - due to the usual: work, family, life.

The scope of the task also became slightly daunting - there are a few general areas that I've not tried to tackle yet at all:

1. Performing the layout on every state change instead of just initially
2. Dealing with how 'native' components could be interleaved with the layout. For instance the children of a button in the gtk version ought to be wrapped in a 'fixed' widget where the context from that point should then be relative to top-left corner of the button.
3. Figuring out how measurements might even be performed in a browser. I've seen suggestions that adds hidden versions of elements to the dom in order to perform measurements, but that seems like it might be a wasteful way to go.
4. Probably more that I can't think of right now...

I did try to merge main into this branch earlier, but I had the idea that the layout functionality might live on PrimitiveView, but after messing about with this concept I figured that this was not the right idea since that required all PrimitiveViews to be able to perform layout in the TokamakCore module, whereas for some views this work must be done in each of the renderers. And this means that the layout must be 'dynamic' (in the sense that protocol conformance must be tested at runtime before calling into the layout code).

I haven't yet looked into all of your additions, but please let me know if there is something you would like to discuss. :-)