Composable builder pattern for system construction and stage configuration #2510
Description
What problem does this solve or what need does it fill?
As the number of different ways to add and configure stages grows, the number of add_system_* variants is undergoing an exponential explosion.
add_startup_system_set_to_stage is not exactly the nicest to write, it bloats our docs and code base, and it isn't composable. We've also had several issues where we've missed one of the variants, completely blocking end users for no good reason.
What solution would you like?
All system properties should be stored on the SystemDescriptor itself, added in a post-fix builder fashion in the same way that labels are.
Instead of add_startup_system_set_to_stage(my_system_set, StartupStage::PreStartup), we have add_system_set(my_system_set.startup().in_stage(StartupStage::PreStartup)).
From an implementation perspective, many of the methods on AppBuilder (see this file) will need to be deprecated.
In exchange, a number of methods will need to be added to ParallelSystemDescriptorCoercion and its exclusive system sibling.
What alternative(s) have you considered?
One nice perk of this design is that it allows the stage that a system is inserted into to be stored as static data.
This means that this work could reasonably be done as part of a refactor where we take a more structured approach to storing App and Plugin data. Clearly structured fields (rather than endless method chaining) would improve clarity / configurability / composability / interop and solve #1255.
In the interests of making these changes easier to review and implement though, I think that this should be tackled first, as it is a prerequisite to that work and should be relatively uncontroversial.
Additional context
AppBuilder is planned to be deprecated for 0.6 as part of the rendering overhaul; collapsed down to just methods on App.
@Ratysz also has plans to simplify and improve the scheduler API, beginning with bevyengine/rfcs#29.
I am unsure which order this issue should be tackled in relative to those two major overhauls mentioned.