Add Taffy layout algorithms

[RagibHasin]

Based on prior works from #140 and #682.

[xStrom]

I don't think we should do this.

There are certainly some immediate benefits, because the Taffy flex/grid implementations are more feature complete than the Masonry ones. However, there are also significant long-term costs. Because then there will be two Flexbox and two Grid implementations that both will need maintenance and care. This also creates a confusing user story, like which Flex should be used? Why are there two?

The implementations won't ever be fully equivalent and will have subtle differences that aren't easy to quickly explain. The differences being mostly around web compat, because that is a Taffy goal, while the Masonry implementation doesn't care about web quirks.

We need to also think about future developent of the Masonry layout system. New features and/or changes to existing features. It will create a situation where either the Masonry layout system will be held back by the Taffy widget because we'll skip adding new layout system features or changing existing ones, or the Taffy widget will gradually become more broken as it won't behave like other Masonry widgets because it just doesn't support the latest Masonry layout features.

None of this is to say that Taffy itself is bad. It's a completely valid choice and many projects are happy with it. However, for Masonry we've kept a fully custom layout system that we have full control over. Sure, it still requires more work. What will help get that work done is more focus, not bolting on alternative layout systems that will demand attention every time we want to change our custom layout system.

I think it is for the good of the long-term health of Masonry to say no to Taffy and to prevent the addition of all the complexity and maintenance burden it would add.