Accept boxed conditions for run_if, and cleanup IntoScheduleConfigs

[ItsDoot]

Objective

• Part of Extensible Schedule Graphs #20115
• Alternative to Create chainable run_if_dyn #18585

We can introduce another layer of traits in order to directly accept boxed conditions as the argument to IntoScheduleConfigs::run_if.

Solution

• Add IntoBoxedCondition trait which is used to convert IntoSystem conditions and BoxedConditon into BoxedConditions.
• Rename the ScheduleConfigs::x_inner functions to add_x/set_x and make them public. These are simply the &mut self versions of the functions on IntoScheduleConfigs, so we should expose them.
• Cleaned up the impl IntoScheduleConfigs for ScheduleConfigs since we now use those add_x functions in the default function implementations in IntoScheduleConfigs.

Testing

Added a new test for supplying a BoxedCondition to run_if.

[ecoskey]

Could this also be solved by implementing System for Box<dyn System>? Ran into a similar-ish thing here and I wonder if that might be a more direct fix than adding traits (and in my case extra methods/boxing). I know the maintainers have been iffy about that in the past though, so idk.

[ItsDoot]

Could this also be solved by implementing System for Box<dyn System>? Ran into a similar-ish thing here and I wonder if that might be a more direct fix than adding traits (and in my case extra methods/boxing). I know the maintainers have been iffy about that in the past though, so idk.

Yea cart has historically wanted to avoid doing that because of potential double/triple-boxing of systems. Note that you can already provide boxed systems via add_systems, this PR is just covering one of the remaining points: run_if.

[hymm]

Rename the ScheduleConfigs::x_inner functions to add_x/set_x and make them public. These are simply the &mut self versions of the functions on IntoScheduleConfigs, so we should expose them.

Not a big fan of these renames add_in_set is a bit confusing if it's add "in set" or "add in" set. What's the motivation here for exposing these methods?

[ItsDoot]

Rename the ScheduleConfigs::x_inner functions to add_x/set_x and make them public. These are simply the &mut self versions of the functions on IntoScheduleConfigs, so we should expose them.

Not a big fan of these renames add_in_set is a bit confusing if it's add "in set" or "add in" set. What's the motivation here for exposing these methods?

ScheduleConfigs currently only allows by-value mutation (except run_if_dyn which is &mut Self), which makes by-reference mutation annoying for outside users, so why not just expose the functions we already have (with better names).

I do agree add_in_set was a bad name and have swapped it to add_to_set, as well a couple other ones in the latest commit.

[pablo-lua]

Good cleanup, it even simplify some functions there. LGTM

[alice-i-cecile]

This seems technically competent (although I have naming quibbles), but I'm not sold on motivation here and I'm leery of incremental change to scheduling.

Blocking per #20115 (comment). This work needs a proper design doc and working group.