Compute content size, padding and border for each node

[nicoburns]

Objective

• Closes Output "scroll width/height" for each node #470
• Closes Expose border calculated value #223

Changes made

• Overflow::Clip variant added to the Overflow enum. Layout with Clip behaves the same as Visible, except the overflowing contents don't contribute to the ancestor nodes' content sizes.
• content_size feature flag added
• content_size field added to Layout struct (stored on Node) and LayoutOutput (returned to parent) structs
• border and padding fields added to the Layout struct
• Implement content_size computation for all layout modes
• Add scroll_width and scroll_height methods to Layout and add tests for scroll width/height
• Remove caching run_mode exception for leaf layout. We now need to run leaf layout

Todo

• Feature flag the block layout implementation
• Feature flag the leaf layout implementation (if appropriate)

Context

Useful for any UI toolkit wanting to implement scrolling (e.g. bevyengine/bevy#8104). Although it's worth noting that this implementation assumes that every node is a scroll node, and it may be possible to do this cheaper if you can avoid that assumption at a higher level.

Feedback wanted

• General code review
• Should this be merged as-is (causes 5-20% performance hit). Or can anyone think of any way to reduce to reduce the performance impact - as far as I can tell is the actually computation of the content sizes from the sizes of the child nodes?
• If it should be merged, should it be enabled by default?

[TimJentzsch]

I have to admit, it's becoming quite hard for me to grasp all the layout logic as it's becoming more and more complex.
I wonder if we can improve this somehow, maybe with more inline docs or with better abstractions or if the complexity of Flexbox and the performance considerations make this a necessity.

Regarding the performance, it would of course be great if we only had to pay this cost if scrolling is enabled, but I assume this would be difficult to implement right now.
I assume Bevy and other clients will always have this feature enabled, so it would be great to reduce the performance cost somehow.
If the feature is enabled by default or not is less important IMO.

[alice-i-cecile]

Should this be merged as-is (causes 5-20% performance hit). Or can anyone think of any way to reduce to reduce the performance impact - as far as I can tell is the actually computation of the content sizes from the sizes of the child nodes?

I'm okay to merge as is: I think this is fundamentally a necessary feature for the spec.

If it should be merged, should it be enabled by default?

Hmm. So ultimately our users are UI crates that consume taffy. Some of them will be simple, and won't support scrolling, others are more complex and do. Unless they make a feature flag to mirror this, that control won't be exposed to users.

In Bevy for example, I would probably push for a mirror of this feature flag, and then enable it by default in Bevy.

On the balance, I think we should keep this on by default, to match our existing policy of enabling default features for multiple different layout algorithms, even if not all of them are useful to all UI crates.

[nicoburns]

There's still a performance hit with this, but it's much better since #579 (now more like 5-8%). So I think I'm going to enable this by default. I suspect we may also need to tweak the computed size in future (as we discover bugs), but I think this is good enough as a first cut at the feature.