Improved system insertion syntax

[alice-i-cecile]

As Bevy gains functionality, the list of possible ways that we might want to tweak a system continues to grow.

Currently, I believe we have the following modifiers:

• which function we're calling as a system
• which Stage we're adding the system to
• which run_criteria it might have
• whether it's thread-local
• whether the system runs once at startup, or runs every frame (probably generalizing to which runner it should use)

Things that might or might not be modifiers in the same sense:

• whether it's an enter / exit system for a particular state
• whether it belongs to a particular system set

In many cases, there are great defaults for this: they're simple systems that live in UPDATE and aren't thread-local. But we need to be able to access all possible permutations of these feature flags, and add_thread_local_startup_system_to_stage starts to get a little cumbersome (and makes things hard to refactor).

As discussed in #ecs on Discord with @cart @smokku @sY9sE33, there's a need for better, more composable syntax than just having wrapper functions.

Desiderata

1. The standard .add_system(my_system) syntax should still just work.
2. We should be able to add on any combination of these feature flags to a particular system.
3. We should be able to extend this functionality to an entire system sets in a single batch.
4. We should attempt to minimize the amount of semantically empty boilerplate required.

Open Questions

1. Should the various simple builder functions such as .add_startup_system continue to exist once a more flexible syntax is introduced?
2. Should we be able to modify systems at run time / in a less local fashion using syntax comparable to the .stage syntax found in Improve usability of StateStage and cut down on "magic" #1059?

Proposals

System Descriptors

  .add_system(system.build()
      .to_stage(Stage::PostUpdate)
      .with_run_criteria(!PAUSED)
      .as_thread_local()
  )

Questions

1. How could we alter the syntax and semantics to help this work with system sets?

Method Chaining

app
    .add_system(physics)
    .to_stage(Stage::POST_UPDATE)
    .with_run_criteria(!PAUSED)
    .as_thread_local()

Questions

1. From a technical perspective, can we get this working with system sets?
2. Do we need a terminator (.finish()) method on it at the end, as @cart suggested?
3. How do we want to handle cases where non-system, non-modifier commands intervene, like .add_resource? This leads to unclear code, but could probably be disambiguated automatically.

[Ratysz]

I'm fond of the nested builders ("descriptors") approach. It should even be possible to ditch the .build() if we put the methods directly on IntoSystem. It also should benefit from some semantic separation: where a system goes should be encoded by the construct the function is called on and any variables passed along with the system, and how the system behaves should be encoded within the system argument itself.

app
    .add_system(system_a)
    .add_system(system_b.run_criteria(sometimes()))
    .add_system_to_stage(STAGE, system_c.run_criteria(rarely()))

stage
    .with_system(system_a)
    .with_system(system_b.label("sys_b"))
    .with_system_set(
        SystemSet::new()
            .run_criteria(next_tuesday())
            .with_system(system_c)
            .with_system(system_d.label("sys_d").run_criteria(occasionally()))
            .with_system(system_e.depends_on("sys_b").depends_on("sys_d")),
    );

There's also typestate pattern, but I feel like it'd be more trouble than it's worth on this scale.