System graph flavors

[alice-i-cecile]

RENDERED

This RFC adds more types of basic system-graph constructs, providing the foundations needed by #33, #36 and other higher level scheduling APIs.
In particular, this extends on the existing "strict ordering" of .before by adding:

1. If-needed ordering constraints, as proposed by @davidscherer in System scheduling bevy#2747, which allow for more efficient many-to-many constraints.
2. Causal ties, which ensure that plugins are harder to accidentally break by providing a tool to link the run criteria of systems.
3. At-least-once separation constraints, which are used to specify the exact "cleanup" logic required by command processing, indexes and relations.

I would very much like to move forward with the "automatically run side-effect consuming systems when needed" approach, allowing us to significantly simplify the design by avoiding a painfully complex satisfiability checker and allowing causal ties to be moved to their own RFC. However, I know this is likely to be controversial, so I wanted to get some initial feedback and show the added complexity needed before swapping over.

[alice-i-cecile]

What if we added an atomic A.directly_before(B) dependency type? Rule would be:

After A has started running, until B concludes, systems (other than the systems that are directly after A) cannot write to the resources or archetypes that A can read from

Effectively, A doesn't look like it's complete to any system other than the one(s) it is directly before until those also finish

[alice-i-cecile]

Closing in favor of #45, which steals almost all of the ideas from this RFC.