Enforce min layout size as window size

[freakboy3742]

On every platform other than GTK, Toga computes an initial minimum layout when a window is first displayed, and applies that minimum size. If the layout changes, the minimum is never recomputed.

This is at least in part because computing the minimum size requires a second run through the layout algorithm.

GTK does do a second layout pass on every layout change... but there's no reason we can't track the minimum size at the same time we're computing the actual layout.

This PR modifies the Pack algorithm to compute the minimum possible layout at the same time as performing actual layout. When a layout has been applied, this the minimum size is then updated onto the window as a new minimum size constraint. On desktop, if that size is larger than the current window size, the window is made larger. On mobile, the window size can't change, so a warning is logged if the minimum layout size exceeds the available size.

This builds on #1996, as it requires the new Container handling. As part of the change, viewport has been completely removed, and Pack calculations have been made scale independent. The layout is now done in an ideal, 96dpi coordinate system; all user-provided sizes are assumed to be in that coordinate system. If the runtime device and platform uses has a different density (something that affects Windows and Android; GTK, cocoa and iOS autoscale to 96dpi equivalents), any container sizing or widget intrinsic size hints provided to the layout algorithm must be scaled into 96dpi layout-compatible sizing, and then scaled back to device coordinates when applied.

This PR requires beeware/travertino#78, adding min size tracking to layout.

Fixes:

• Fixes Report/react to layout geometries that won't fit in the availble window #908
• Fixes Android layout seems to ignore top header #968

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

Other things that should be addressed in this PR:

• The ScrollContainer test tolerances should be tightened up.
• On Winforms, there is a known bug that the minimum window height is too short because it doesn't take the menu bar and toolbar into account. For example, see examples/resize.
• Possibly related: Android layout seems to ignore top header #968

[mhsmith]

• The ScrollContainer test tolerances should be tightened up.

Done.

• On Winforms, there is a known bug that the minimum window height is too short because it doesn't take the menu bar and toolbar into account. For example, see examples/resize.

Fixed.

• Possibly related: Android layout seems to ignore top header #968

The original issue is now fixed (though possibly by an earlier PR), so I've added it to the "fixes" list above.

However, it looks like there's a bug with Pack propagating minimum sizes through intermediate boxes. Try the example at #968 (comment). The inner Box height is unspecified, so it now correctly has a constant height of 100 (from the MultilineTextInput's minimum size), and the minimum window height is also correct. And if I set the inner Box to flex=1, it correctly expands to fill the extra space. But then the minimum height of the window doesn’t take account of the MultiLineTextInput anymore, only the Button. This behavior is the same on both Cocoa and Winforms.

[freakboy3742]

However, it looks like there's a bug with Pack propagating minimum sizes through intermediate boxes.

Confirmed I can reproduce this problem; still digging to find the cause.

[freakboy3742]

However, it looks like there's a bug with Pack propagating minimum sizes through intermediate boxes.

Confirmed I can reproduce this problem; still digging to find the cause.

Found it - the minimum allocation of grandchildren wasn't being propagated into the minimum size of flexible children. Fix and test pushed.

[mhsmith]

I've fixed the Android JavaScript problem, and all tests are now passing in CI with the second most recent commit.

The final commit isn't passing yet because Travertino 0.3.0 doesn't exist yet, but it should pass on a rerun once it's been released (beeware/travertino#78 (comment)).