Fix Portal size constraints.

[xStrom]

Portal already had constrain_vertical and constrain_horizontal properties but these were only used to hide the scrollbar. They didn't actually affect the child layout in any way.

Indeed, the Portal layout implementation had a simple hardcoded let max_child_size = bc.max(), meaning that the child was always fully constrained.

This PR implements actual constrainment logic, configurable with the aforementioned properties. When not set to constrain, the child gets unbounded constraints. After all, that is the main point of Portal - to be able to scroll over giant children.

Also, when an axis is constrained, Portal now also ignores mouse wheel scrolling in that direction, in addition to hiding the visual scrollbar.

[PoignardAzur]

When not set to constrain, the child gets unbounded constraints. After all, that is the main point of Portal - to be able to scroll over giant children.

I deliberately removed that behavior, and I don't want it to be added back.

There are a lot of widgets that return bc.max() as their size; if you give them infinite constraints, the layout code will panic. (Which is an improvement over the previous status quo, "the widget will fail to render for unclear reasons"). Yes, we could add a special case to all these widgets along the lines of "if constraints are infinite, return X instead of bc.max(), but I'm also against such special casing.

I think we should discuss this on Zulip.

[PoignardAzur]

Is this superseded by #1560?

[xStrom]

Most of it yes, but not 100%. The mouse scroll stuff is not in #1560. Let this remain open for now as a temporary issue tracker. I'll extract out the non-superseded parts after #1560 lands.

[xStrom]

Alright, this is now fully superseded by #1560 and #1583.