Fix flexbox baseline alignment

[nicoburns]

Objective

• Fix flexbox baseline alignment implementation (fixes baseline alignment tests imported from yoga)
• Refactor flexbox baseline alignment implementation so that it doesn't require directly accessing the layout of descendant nodes other than direct children (required to make it's baseline alignment interoperate with Grid and other layout modes properly)
• Optimise baseline alignment computation so that child baseline are only calculated when necessary

Context

Note: This PR depends on #320 which in turn depends on #317 both now merged!

I did a quick run of the benchmarks vs. main to check for regressions, and actually I'm seeing mild performance wins (10% - 30% on some benchmarks) on quite a few of the benchmarks. There is also a ~10% regression on a couple, but those are the very smallest ones that are completing in single-digit microseconds anyway, so I'm not going to worry too much about those (we probably ought to remove those super small ones at some point - I don't think they're very representative of real-world performance).

Feedback wanted

Does changing each algorithm's perform_layout function to return:

struct SizeAndBaselines {
   size: Size<f32>,
   first_baseline: Point<Option<f32>>,
}

instead of Size<f32> as I have done in this PR seem reasonable? This is instead of the 3rd layout method proposed in #28 (comment)

[nicoburns]

This still doesn't implement baseline alignment for CSS Grid, but I now think I'd like to merge this without that to unblock #326. These changes (fixing baseline alignment for flexbox, and refactoring the flexbox implementation so that it doesn't require accessing the layout of descendant nodes other than direct children) are worthwhile on their own, and baseline alignment for CSS Grid can follow in another PR.

[alice-i-cecile]

This name isn't very clear.

[alice-i-cecile]

Ditto on the name here.

[alice-i-cecile]

Hmm. I'm not very happy with this naming / docs. Maybe something like UnifyingLayoutAlgorithm?

[nicoburns]

This struct actually disappears in my latest version of #326, as I've made the "generic" algorithm and the "leaf" algorithm operate on &mut Taffy rather than &mut impl LayoutTree (so they don't fit the LayoutAlgorithm trait anymore). This allows us to remove measure_funcs from the LayoutTree trait and make them an implementation detail of our Taffy storage implementation.

[alice-i-cecile]

Good I'm fine to wait.

[alice-i-cecile]

Some feedback on structure and docs. I would like to get this merged quickly though, so feel free to defer some of the work (e.g. the trait refactor) to a follow-up PR.

[nicoburns]

@alice-i-cecile I've renamed the compute_generic functions back to compute, which is what they were already called. So I think it can now safely be said that the interface is no worse than it was. In any case, as these traits/functions are currently private, I'm not going to worry about too much (we can easily change this later if we want to). I suggest we bikeshed this in #326 (which does make the LayoutAlgorithm trait public) and also makes major changes to the public interface exposed through the LayoutTree trait.

Is there anything else blocking this?

[alice-i-cecile]

Nope, this now LGTM.