Scheduler proposal

[Ratysz]

The scheduler provided by bevy_ecs is good enough, but it could be better: more expressive syntax, more features, greater flexibility and maintainability. This proposal suggests expanding the API, enabling further work on internals.

Recommended reading, I will be using the terminology introduced there. (Please do report any inaccuracies in the article.)

Right now, stages are the only mechanism to express an execution order dependency between systems in the case where one can't be inferred, and it's not possible to explain to the scheduler that an inferred dependency can be ignored. There should be ways to do both.

Besides, stages should really be used to express execution order between groups of systems, not individual systems.

With stages cleanly decoupled from each other, it's possible to treat each of them as a separate schedule for executor (the scheduling algorithm) purposes. Ideally, each stage should encapsulate the systems and the executor operating on them.

This allows independently specifying which algorithm is used with a stage, enabling users to choose fundamental things, like having inferred execution order or not.

The crate's API should allow using stages independently of the schedule. The schedule abstraction itself could even be moved from bevy_ecs to the engine, seeing as it wouldn't be required for stand-alone use.

So, current vision:

• Schedule is an ordered collection of stages, its interface deals with adding, removing, and mutably accessing stages, as well as running the whole thing, which runs the stages sequentially. It doesn't care what's going on inside the stages.
• Stages encapsulate a collection of systems, and an instance of the scheduling algorithm used with them. Their interface varies between specific stage implementations, but generally deals with adding or removing systems, specifying (or un-specifying) execution order between them, and running the stage. Each stage implementation has its own requirements and makes its own guarantees regarding execution order, strictness of system disjointedness detection, etc.

The current executor should be rewritten as a stage and given an interface to manipulate dependencies, in addition to retaining its current behavior. More stages should be implemented, not necessarily as part of bevy_ecs - their modularity enables external algorithms (example?).

(Minor thing from the current implementation: thread-local and modifying systems are conflated and intertwined. I suspect that detangling the two will greatly improve maintainability, although that would likely touch more than just the scheduler.)

Questions:

• How will this play together with scenes, if we do decide to mingle their domains?
• What bevy_ecs-side things should we provide for stage implementors, besides the system abstraction? Maybe the modifying systems mechanism (the bit that merges Commands at the end of a stage) can be decoupled in a reusable way?

I will start working on mockups in the meantime.

[Ratysz]

This is pretty much resolved by #1021. What I referred to as scenes in the questions section is addressed in the PR as well, in the form of "states".