remove ParallelIterator

[mockersf]

ParallelIterator was only mentioned in a few docs, I tried removing it and... everything still works! 😌

While not used by Bevy, it may still be useful as a public trait for third party to implement?
I think it should have been removed with ECSv2.

[fopsdev]

this has nothing to do with:
#2088
right?
(par_iter != ParrallelIterator as mentioned here)

[cart]

Nope this is definitely the ParallelIterator implemented in #2088. We should probably have a discussion that weighs the complexity cost of maintaining ParallelIterator + another query iterator variant (but with way more flexibility) vs committing to only supporting par_for_each / par_for_each_mut at the cost of disallowing other interesting iterator patterns.

We have a lot of iterator variants on the table now (QueryIter, BatchIter, QueryCombinationIter, for_each, par_for_each). Given the complexity of bevy's query iteration logic, we should sort out the best way to manage complexity across so many variants (ideally without compromising performance or api quality).

Pulling in @TheRawMeatball, @Frizi who are both writing iterator code and @BoxyUwU who is adding iterator features like Relations.

[mockersf]

oh it had nothing to do with the first impl of #2088, but it's used by the rewrite

If we keep it, par_for_each* should probably be rewritten to use it instead of having their own logic

[cart]

If we keep it, par_for_each* should probably be rewritten to use it instead of having their own logic

The downside of adapting par_for_each is that we need to do the "dense check" branching per-next-call instead of once at the beginning. We should bench that to see what the cost is.

[CGMossa]

I'm very much interested in more parallel capabilities than for_each and for_each_mut. I've looked in the PRs, discord and I see that there is a discussion that needs to be had, before this progresses.
Let me know if I can aid it in any way.