Add dedicated component for specifying draw order in 2D

[tim-blackbird]

Objective

Move away from basing draw order on global Z translation in 2D.

Solution

Add a new Sorting component to control the draw order of 2D entities.

This solves the issues of scale on the Z axis and rotation on the X and Y axes affecting the draw order of child entities.

Closes #4149

We could later expand this component with desired features like sorting groups or y-sort.

This PR should (probably) be consider together with #8268.

Benchmark

I've tried to benchmark the following command but I was getting very inconsistent results.
cargo run --release --example bevymark -- --waves 1 --per-wave 50000 --benchmark
I now seem to be getting consistent results again that show a large improvement from this PR, but quite frankly I have no idea why that would be, so I don't trust it :v
Probably something to do with my machine/os.

It would be great if someone could run this benchmark on their own machine to verify :)

Changelog

Added Sorting and ComputedSorting components.

TODO

• investigate performance
• update examples
• migration guide

[superdump]

I take this PR as trying to provide a story for managing draw order of 2D entities like sprites or 2D meshes.

This solves the issues of scale on the Z axis and rotation on the X and Y axes affecting the draw order of child entities.

Is there a reason why one can just not scale the z axis? Given draw order is done based on translation z, rotations should have no impact on it. Are you saying that rotations do impact draw order? If so, in which cases? I could imagine that maybe there is some precision difference in some case where two sprites are at the same z and they have been rotated. But then why can’t one just put them at different z?

In general, I’m wondering why things like z index and this sorting component are needed and why just translation z is insufficient for 2D use. And this isn’t a criticism directed at you, rather I get confused why things like this are necessary when there is already a solution and I wonder if we should just make it clearer that people need to set different translation z to affect the order the items are drawn.

Another example - y sorting is then just mapping the y coordinate appropriately and writing it to z and it would just work.

Another question - what do other engines do and what/why do people doing 2D say they like what those other engines do?

Finally, as mentioned in another issue, I think having 2D user space components for those who prefer it could be fine. But it can also be too constrained for some as rotations about x and y may not be possible for example. So I think for flexibility, those should be converted to 3D on extraction, and users can choose whether/when to use the 2D or 3D transforms for 2D.