Replace Sets with Schedules / unify adding sets to schedules

[vonforum]

What problem does this solve or what need does it fill?

After #8079, adding systems to schedules is unified under a single API, which is great. Configuring sets, however, still has multiple ways of doing it. Plus, systems belong in multiple different "types" of "collections" (schedules and sets). This was the case before as well, with systems having to belong in a CoreSet plus the main schedule, but now the core sets have been replaced with separate schedules.

What solution would you like?

Do the same for all notions of "sets", i.e. unify sets and schedules. Since systems have to belong to a schedule anyway, I propose replacing sets with nested schedules. Instead of configuring a set as you would now, you instead can configure schedules and nest them. In function, this would be the same as the current way of configuring a tree of sets and adding your systems to those, inside a schedule. In addition to making the API smaller and cleaner, it would simplify code for structuring your systems. Currently, if you want to create a system in a set, you have to annotate every system with the set it's in, in addition to its schedule

app.configure_sets(PreUpdate, (A, B).chain());

app.add_systems(
  PreUpdate,
  (
    a.in_set(A),
    b.in_set(B)
  )
);

However, after this, you could add directly to your nested schedule (just an example)

app.add_schedules(PreUpdate, (A, B).chain());

app.add_systems(A, a);
app.add_systems(B, b);

This also removes the need of having to "know" what schedules each set belongs to if you want to add your system to it, e.g. in plugins.

What alternative(s) have you considered?

Just configure the configure_sets function to also take a single set, to at least be consistent in not having many functions do the same thing.

[mscofield0]

Has anyone done anything with regards to this and #9792?