Remove systems from schedule

[hymm]

Objective

• Add ability to remove systems from a schedule.
• Fixes API for dynamic management of systems (adding and removing at runtime) #279.

Solution

• add remove_systems_in_set method which removes all the systems by their set name. In most cases systems are added to a schedule once, so just passing the system (which is an implicit set by it's type name) will just remove the one system. If a system is added multiple times such as apply_deferred, then you may need to give the system a unique set, if you just want to remove just one system.
• The method also tries to remove all the configuration for the set and the systems found.
• We need to pass world to the method because user build passes are allowed to write to the world.

Testing

• Added some unit tests.

Future work

• In the future of systems as entities this will probably look much different. We'd probably store all the edges as relationships, so hopefully cleanup would be easier.
• It'd be better if remove_systems_in_set could take a tuple of system sets. I looked into using IntoScheduleConfigs, but that won't work since the system set version of it errors if you try to pass a system type set. This would allow for less rebuilding of the schedule. The schedule needs to be rebuilt to each call to be able to find the system set.

[andriyDev]

Exciting! Nice to see our schedule API getting more dynamic.

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[alice-i-cecile]

This fixes a long-enough standing issue that I'd like a release note.

[alice-i-cecile]

The fundamental strategy seems good, and there's nice tests. Before we merge though:

• this fixes an important and old enough issue that I think this needs a release note
• I would like a few convenience APIs for this, ideally on World, App and Commands
• I would like a brief note in the docs comparing and contrasting this to run conditions

I am very excited about this work though; please let me know if you don't have time and I'll finish this up for you.

[onkoe]

Ooo, cool change!

There are a few doc changes I recommend to the primary functions. I also have some veeery optional docs for the tests:

Tests

Comments

I added some doc-comments to the tests. The other ones don't really do that, so feel free to leave em unchanged.

It's my preference for module-name-irrelevant stuff like this (but, tbh, it's nice for all tests lol)

World

It might be nice to have a quick schedule.run() test on the changes. Just to ensure things work right in practice aside from theory :)

[chescock]

Ooh, this is exciting!

[hymm]

Updated the pr to have some removal policies, where we have options to

• remove only the systems, but leave the set in case a user wants to reuse the constraints on the set
• fix the transitive dependencies automatically. I think this is good for cases where you only want to remove a set or system. Not fixing the dependencies is useful for where you'll be adding more sets and systems and fix the ordering then.

I'm not 100% convinced that a flat enum is the best choice here. It might be better to have some sort of configuration struct. Just brainstorming, but some other policies could be to remove sub sets, or run conditions.

[alice-i-cecile]

@chescock's suggestion is solid and we might as well clean this up now, but I'll merge this next Monday if you don't have time to get to that.

[hymm]

I still need to update the release note