Yoga layout

[IceReaper]

For an example what exactly Yoga is, and how it works, see: https://yogalayout.com/
Basically all old Bounds stuff is completely replaced by a proper layout engine, which supports basics like margins, borders, padding and min/max and preferred width/height attributes.

Whats missing:

• The yoga dlls!
  They are currently build by hand under Ubuntu 19.04 by building the official repository version.
  Yoga.zip
  And here are the sources (which are un-editied variants from their latest release) along with the makefile i added to build the native binary (did not want to install their whole build environment)
  Facebook.Yoga.zip

Whats not part of this PR:

• Refactoring of all the chrome yaml files to make use of the flex layouting.

Features i want to add in the future:

• addition of more css styles for gradients, shadows, border images, etc.
• support for auto layouting of nine-patches for borders
• Implementation of "classes" which can be used to group the style of widgets
• rewrite all the uis to make use of the flex layout

[pchote]

Why is the * → Classic* rename needed? Does YogaNode already implement these? If so, why can't our legacy layout code be changed to use those values (with transformations if needed) when evaluating the bounds?

[IceReaper]

The core idea is to remove the classic behavior in the future. The whole evaluation of PARENT_RIGHT etc has to be removed (as the yoga layout supports this anyway, just differently).
First yoga has Width and Height props, however i think its way cleaner to make use of the layouting system properly when using those, moving the custom calculation stuff into different props to make clear you are using an old feature here. X and Y are ofcourse not part of yoga, as it has Left,Right,Top,Bottom, however as they belong to the same concept of above, i renamed those too.
Basicaly you can use the proper flex layouting system which yoga provides, or the "classic" one, which may hopefully be removed in the future.

The alternative would be to evaluate the expressions, and then setting the yoga values, but this also means in the future that dropping this feature will break things heavily out of nowhere. Yogas implementation works slightly different and is superior. Due to the layout engine, we can properly re-align stuff on resize. Using calculations from "right" to position X will completely break here as we cant teach the yoga lib to hook our custom attribute calculations every time it relayouts.

So the basic idea is for a foreseeable time, we have both layout systems, using the proper keys for the proper flex layout system, and the classic* prefixed ones for the classic implementation while being available. So people can search for those keys in their yaml and ports their uis over over time.

[pchote]

Summarising my thoughts from Discord: I think the best (and, to be honest, probably the only realstic) way forward with this is to have this first PR implement a shim / wrapper that translates between the classic interface and what Yoga expects. This will let us focus on the way Yoga works instead of being drowned by 15k lines of yaml and ChromeLogic renames.

For example, instead of replacing w.Bounds.Width → (int)widget.LayoutWidth, w.Bounds.X → (int)label.LayoutX, and so in all of the chrome logic classes we could change Widget.Bounds to a new YogaBoundsBridge class that defines properties int X { get { return (int)LayoutX; } }, int Width { get { return (int)LayoutWidth; } } and so on.

Something similar can hopefully done with the yaml interface so that the current definitions remain compatible unless we/modders explicitly opt in to Yoga-powered flex or absolute positioning.

This will let us focus on the behavior without having to spend hours focusing on thousands of lines of mechanical renames, which are likely to conflict and regress as any other PRs that touch the UI are merged. Removing the shims can be left to a future perf task once we know it is otherwise integrated and working well.

[IceReaper]

Ill redo the implementation from scratch to avoid the need to merge all the new stuff.

[pchote]

Activity is slowly progressing on this behind the scenes (the focus so far has been on migrating to .NET core and sorting out a toolchain to compile native Yoga binaries), but it will likely take a while longer before this can be updated for a serious rereview.

Closing for now to help clean up the PR queue.