Easier mutation of schedules within the Schedule resource

[lee-orr]

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

Right now, if I want to add systems to a schedule to the schedules resource directly (not via an App), I have to manually request it, check if it exists and if not create and insert a new schedule.

Something like this:

        match schedules.get_mut(startup) {
            Some(schedule) => {
                schedule.add_systems(|world: &mut World| {
                    let _ = world.try_run_schedule(StateTransition);
                });
            }
            None => {
                let mut schedule = Schedule::new(startup);

                schedule.add_systems(|world: &mut World| {
                    let _ = world.try_run_schedule(StateTransition);
                });

                schedules.insert(schedule);
            }
        }

Unlike HashMap, for example, which has the .entry(&mut self, key: &K).or_insert( ... ) pattern that lets you work though it as a single step.

What solution would you like?

• Add a Schedules::add_systems(impl ScheduleLabel, impl IntoSystem) function - essentially moving the abstraction for adding systems further into the schedules resource from the sub_app (still using sub_app to access it as well).

What alternative(s) have you considered?

• Adding a Schedules::get_or_insert_mut(&mut self, label: impl ScheduleLabel) -> &mut Schedule method that allows you to get a schedule at a certain label - and creates it if it doesn't exist. I feel that this is less ergonomic than the above suggestion, but might add some additional capabilities in limited situations - so it could still be worth adding.

• An approach similar to HashMap - where you use Schedules::get(..._).or_insert(...). For "HashMap" - we don't know the exact structure of a new Value, but since here we do - I think the above two options work better on the whole.

Additional context

Brought up by @MiniaczQ in #11426 (comment)

[alice-i-cecile]

Yep, I think I'm on board with this!

[lee-orr]

Can you assign this to me please?

[lee-orr]

@alice-i-cecile Would it be controversial if I added "ignore_ambiguity" & "configer_sets" to the Schedules resource as well? They have the same basic access pattern, so it feels like a good fit.

[alice-i-cecile]

No objections at all. I think that's the right choice, and is a really nice UX feature for those using bevy_ecs on its own.