Run system from &mut World

[alice-i-cecile]

Objective

Systems are an ergonomic and expressive API for performing well-encapsulated complex logic.
However, you could not easily use them while working directly with &mut World for custom commands, exclusive systems, writing tests or bare-bones bevy_ecs usage.

Solution

Adds a World::run_system method, which immediately executes a single system in sequence and then flushes any Commands (or similar system parameters).

This is also very useful for users who may want to construct their own game loop in part or whole, sacrificing parallelism for simplicity and control.

Notes

Closely related to #2234, and borrows aggressively from the implementation there. Thanks @mockersf for pointing me in the right direction <3

[alice-i-cecile]

I considered an API for chainable systems, accepting Box<dyn System> as the method argument type. However, like basically every other time I've examined system chaining, I could not find real world applications for this.

If others have compelling ideas, it can be added in this or a future PR.

[cart]

I'm not convinced that this biases toward the right outcomes. It encourages people to re-create systems every frame because it requires taking ownership of the system. Instead I think we should make Systems themselves easier to run with the correct lifecycle (with a mutable system borrow). Ex: System::run_but_do_everything_a_schedule_would(&mut self, &mut world).

[alice-i-cecile]

I hadn't noticed the ownership issue. I agree, that needs to be fixed one way or another.

Ah, so make this a method on systems instead? I can get behind that; the reduced discoverability isn't bad since I'm aiming to include this in the new ECS chapter.

I don't think I can pass in the argument here by reference since it's impl IntoSystemDescriptor, but I'll try that first...

[alice-i-cecile]

    pub fn run_system<Params>(&mut self, system: &(impl IntoSystemDescriptor<Params> + Clone)) {

So this compiles, but requires Clone. But then the examples no longer work due to Clone being missing on the functions. We could make Clone required by IntoSystemDescriptor (which could be handy for dynamically arranging the schedule later??) but I think the proposed approach is superior.