Plugin System Replacement: Fine grained schedule modding

[ItsDoot]

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

I want to give Plugin consumers an extra level of fine tuning by allowing them to replace preexisting systems in a schedule with their own system.

What solution would you like?

When system foo is replaced with system bar:

• foo is removed from the schedule, and bar is added.
• All SystemSets that foo was in, bar should be added to.
• Preexisting schedule constraints for foo should be copied over to bar.
• Any schedule constraint added later to foo should be instead rerouted to bar.

Suggested API:

impl App {
    // Note that its some new singular `IntoSystemConfig` type rather than the plural `IntoSystemConfigs`.
    // Allowing multiple systems on either side would make this too complex.
    pub fn replace_system<A, B>(&mut self, schedule: impl ScheduleLabel, from: impl IntoSystemConfig<A>, to: impl IntoSystemConfig<B>);
}

This also means the system to be replaced must be nameable/visible (non-private) to consumers.

What alternative(s) have you considered?

Require consumers to replace whole Plugins.

[alice-i-cecile]

Related to #2160, and depending on the implementation details, #279.