refactor: layout performance

[temper357]

通过重构 layout constraints 逻辑，减少不必要的 constraints 计算，提升 layout 性能。

优化策略

• 将原先过程式递归计算 logical size 逻辑重构成声明式 getter，提升程序可读性，并且通过缓存的方式提升性能，由于 constraints 在 RenderObject tree 上是从上至下计算，因此一个 renderBoxModel 在 layout 阶段计算 logical size 时通过直接通过 parent 的 logical size 已经计算出来，可以通过缓存的 parent logical size 直接得出结果，不需要每次向上递归计算，在多层嵌套容器中能节省递归的时间。
• 保证在一次 layout 过程只进行一次 logical size 的计算。
• 在计算 layout 换行的 constraints （contentMaxConstraintsWidth）同理复用以上缓存逻辑，不需要每次通过递归进行计算。

性能数据

构造了一个贴近实际业务场景的 benchmark，包含 1500 个 Flex 容器，样式与 rax-view 组件中的样式对齐，容器最大嵌套层级为 10 层。

下表记录了优化前后 layout 时间与渲染总时间的 5 次数据的平均值：

	layout 时间(ms)	渲染总时间(ms)
优化前	12.342	339
优化后	6.792	318

测试结果：通过对比发现优化后 layout 时间减少约 45%，渲染总时间减少约 6%。

从上面结论看出渲染总时间的提升幅度远小于 layout 时间提升幅度，怀疑时间主要由消耗在指令的传输上，修改上面的 benchmark 将 rax-view 组件中自带的一些默认样式删除，删除的样式占原来样式的 50% 左右。

"borderColor": "black",
"borderWidth": "0px",
"borderStyle": "solid",
"boxSizing": "border-box",
"alignContent": "flex-start",
"margin": "0",
"padding": "0",
"minWidth": "0"

测试结果：优化后渲染总时间下降到约 235 ms，相对于样式删除前时间减少约 26% 。因此下一步优化的重点策略需要放在公共样式的复用上。

[andycall]

需要结合这个 PR #878 编写有关性能优化场景的测试用例，将理论上的优化通过测试沉淀下来。毕竟后续更改有可能会 break 掉优化

[andycall]

需要编写 profile 测试

[yuanyan]

应该是把样式放到 dart 侧来生效，这样才是区别才只剩下传输

[yuanyan]

需要结合这个 PR #878 编写有关性能优化场景的测试用例，将理论上的优化通过测试沉淀下来。毕竟后续更改有可能会 break 掉优化

我们需要先建立起性能beachmark建立起基线，这块 @wssgcg1213 回在 github actions上建立一套