Consider removing System::world_post_processing()

[Anders429]

I initially added this as a way to allow a system to modify a World directly, allowing it to, say, compile a list of entities to add, and then add them after the system has processed. However, this same logic could easily occur outside of a system. The reasoning for adding it to the system itself was to allow post-processing to occur between stages in a Schedule, but I am coming to change my thinking on this.

Having processing occur between schedule stages makes optimizations such as #73 difficult to implement in an understandable way. It is tough for a user to be able to reason about when changes to a world are made if stage boundaries are not consistent for every single run of a schedule, and something like #73 would mean that stages could change depending on what archetypes exist in the world.

It seems that, rather than dealing with complicated stage boundary rules, processing at a stage boundary should be eliminated entirely. If a user wants processing to occur at a stage boundary, that boundary can be created by defining two separate schedules and running them in sequence, with whatever processing they need running in between those schedules. This is the same thinking behind the removal of the flush task from schedule creation in #142: if a user wants there to be a barrier between stages there, the easiest way to allow this is to require defining an entirely new schedule.