Deduplicate App <-> World APIs

[BenjaminBrienen]

It feels like that method would make sense as modify_world? Overall I think that the App <-> World duplication / API mess around multiple worlds needs a real design to solve, and we should be nervous about just adding a dozen little fixes.

Originally posted by @alice-i-cecile in #16977 (comment)

[BenjaminBrienen]

I intend to create a "spike" PR to see if my idea for a single helper method to make the entire world API available while building an App is a good design. Feel free to discuss ideas!

[alice-i-cecile]

The big challenge here is that half of Bevy's API / design is built around a one World <-> one App design, and the other half is kind of trying to support multiple worlds (currently via SubApps). Sticking with SubApps might be the right move, but I'd like a real design for them.

Some ideas:

1. If we're planning on always having a strict one-to-one correspondence, I would be tempted to use a Deref / DerefMut pattern to get delegation from App -> World. Unfortunately, that doesn't work: the chained builder pattern will break since you'll have a &mut World when you want a &mut App.
2. We could push users away from the builder pattern, by using a structured approach to plugins, where you have a dozen different methods, one for each kind of API. See Order independence of App construction #1255 for more background on this.
3. We could move all of the common methods onto a trait. Much less discoverable, but tidier.