System Lifecycle Rework: all Systems are initialized by definition

[cart]

Note: This is just very rough experimentation. I (currently) have no intention to move this forward as-is ... I just created it because people are discussing reworking system descriptors and scheduling right now and this change is something that relates / that I've been wanting to explore for awhile.

This does the following:

• Systems are "initialized" by definition. The "system initialization" lifecycle has been completely removed. IntoSystem takes a world reference and is responsible for initializing the system.
• FunctionSystems now use SystemState internally, unifying them as alluded to in [Merged by Bors] - Add new SystemState and rename old SystemState to SystemMeta #2283. The impl is much smaller / simpler now
• SystemDescriptors / ExclusiveSystemDescriptors now store functions that take a World and return a System.
• Adding a SystemDescriptor to a Schedule therefore requires a World reference. For Apps, this means users don't need to care because we can abstract this out. For raw Schedules / Stages, naively this means they need to accept a World reference, which significantly affects ergonomics. If we were to move forward with this, we would (1) remove all IntoSystem-related methods from Schedule and Stage in favor of accepting "boxed ready-to-go" systems. This would make them much simpler / might improve compile times (2) for direct bevy_ecs users that can't use App, add relevant StageBuilder and ScheduleBuilder types that abstract out the World requirement. alternatively we could just merge bevy_app into bevy_ecs.

The things this accomplishes:

• One less thing Systems need to do
• Simpler / smaller implementation that allows code reuse
• Systems no longer need to store their param state in an Option or unwrap it on every run
• Systems no longer need to store their Config indefinitely. It is only in memory when the app is being built.
• Things running systems and run criteria (like the parallel executor) no longer need to worry about ensuring everything is initialized, which makes the code smaller/simpler/mistake proof.

This comes at the cost of:

1. Systems types cannot be created and stored without a World. This makes some patterns harder (ex: see the changes made to the old renderer's graph init ... this was quick and dirty. Fortunately we dont need that pattern in the new renderer). People that really need this pattern (which honestly should be discouraged generally) can just use SystemDescriptors instead of boxed Systems.
2. Schedules and Stages cannot add new systems without a World reference. This makes sense to me because they are the "baked and ready to go" types. In situations where a world isn't available, we could have intermediate types like StageDescriptor. But I expect App to meet basically everyone's needs in practice.

[cart]

This touches a lot of stuff and most of it is just noise. The most relevant changes are in function_system.rs, the System trait, system descriptors, and the executor.

[alice-i-cecile]

alternatively we could just merge bevy_app into bevy_ecs.

I'd prefer not to do this. The standalone bevy_ecs users that I've talked to tend to have very unusual data-flow patterns and the current Schedule abstractions tends not to work well for them.

They also tend to care about compile sizes and dependencies in ways that other Bevy users don't.

[alice-i-cecile]

I love the reduced boilerplate needed here.

[alice-i-cecile]

Yeah, that seems like a weirdly pathological thing for users to do.

[alice-i-cecile]

Deeply nested resource_scope's seems a bit suspicious. Is this driven by the other changes in this PR?

[cart]

This was the "quick and dirty" solution I called out in the description. The better fix would be to adapt the Render Graph to account for the System lifecycle, but thats more work than I wanted to invest in a proof of concept.

[cart]

Worth considering but this is way out of date and would need significant reworks at this point.