Enable queue phase parallelization by using Parallel to back RenderPhase

[james7132]

Objective

Part 2 on the quest to resolve #3548. Many of the queue and prepare systems are unable to run in parallel, creating a potential CPU bottleneck when dense and varied scenes.

Solution

Use Parallel, introduced in #7348, to provide a cleaner implementation of #4899's thread-local queues, so systems can add phase items to the queue without needing a mutable reference to the render phase. As multiple systems with read-only access can parallelize under Bevy's system executor, many of these systems are "read-only" in the eyes of the scheduler, and thus do not block them from running in parallel with each other.

This potentially adds a bit of additional overhead on a per item basis, due to needing to fetch the thread-local queue for each item, though it may be mitigable by providing a RenderPhase::extend option that takes an iterator instead of adding items one by one.

As a additional optimization, this PR includes a change to Parallel::drain_into to avoid copying if the output Vec is known to be empty to avoid the copying overhead when there's only one system that enqueued items before sorting.

IMO, this design is much cleaner than the one in #4899, though it may be a bit rough to grok for people seeing it for the first time.

Performance

TODO

---

Changelog

Changed: RenderPhase::add now only requires a Changed:RenderPhase`'s fields are now private

Migration Guide

TODO

[superdump]

LGTM, pending benchmark results.

[IceSentry]

Currently, these changes would only be applicable to the SortedRenderPhase. I'm not sure if it's possible to do the same thing for BinnedRenderPhase. The way RenderPhase are used has also changed quite a bit since this PR. Fixing the conflicts and making it work with BinnedRenderPhase seems like non trivial work and seems to me would require a new PR built from scratch.

So closing for now, but if you disagree with me feel free to reopen it.