Implement parallel contiguous iteration.

[pcwalton]

Many of the most expensive systems in Bevy search for changed components and process them in some way. Currently, those systems must check every change tick of every instance of the components that they care about in order to determine which instances of the components have changed. This has become a major bottleneck and is causing Bevy to be unable to scale to large scenes and/or to lower-end hardware.

PR #25157 leverages the existing contiguous iteration query mode to provide a solution to this problem. It introduces summary ticks, which allow contiguous iteration to skip entire tables if the query machinery can quickly prove that none of the relevant components within have changed.

Unfortunately, PR #25157 alone is insufficient to solve the problem in practice, because contiguous iteration mode doesn't support parallel iteration. Most of the expensive systems that we need to optimize in order to scale better--transform propagation, visibility propagation, and mesh instance extraction--are already heavily parallelized. Making them sequential would regress them too much in the case in which there are many changes. Therefore, contiguous iteration needs to be made parallel, which is what this patch does.

It might seem at first that nothing needs to be done. After all, contiguous iteration provides slices of component data, which can be readily iterated over in parallel via the methods in bevy_tasks. The problem is that doing so naively will result in spinning up the parallel infrastructure anew for every table. This is expensive for real applications, which often have many tables. The existing par_iter and par_iter_mut methods on queries are optimized for precisely this case: they can buffer rows from multiple tables together and dispatch chunks that span many tables at once to worker threads in order to amortize the overhead. Furthermore, they spin up the parallel infrastructure once per query, not per table.

This patch brings the existing par_iter and par_iter_mut infrastructure that standard query iteration currently enjoys to the contiguous setting. The batching code is virtually identical to that of par_iter and par_iter_mut, including the infrastructure that can group rows that belong to multiple tables into single chunks that are dispatched to threads. The only difference between standard par_iter and contiguous par_iter is that, when a portion of a chunk spans a single table, that portion is presented as a series of contiguous slices via the ContiguousQueryData trait.

Coupled with PR #25157, this commit provides a complete solution to the performance problem that results from having to check large numbers of change ticks to determine which components changed. This PR and PR #25157 together enable the most expensive systems to migrate to contiguous iteration without sacrificing the parallel gains they currently enjoy when large numbers of changed components actually need to be processed.

I did a performance test in which I created a version of extract_meshes_for_gpu_building that leverages parallel contiguous iteration from this patch and summary ticks from PR #25157. After applying summary ticks to all the relevant components, running many_cubes --instance-count 1600000 --no-cpu-culling results in an improvement in extract_meshes_for_gpu_building of 5.13 ms to 0.039 ms, a 132× speedup.