Order independence of App construction

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

As with our previous discussion on implicit ordering of systems (see #1144), insertion order mattering is frustrating to debug at scale and can make refactoring more painful.

In addition, this avoids a common beginner pain point, where they'll insert a resource after it's used and then get an error about the resource not existing.

**What solution would you like?**

Collect all of the App methods, then process them more holistically (such that order doesn't matter) when `AppBuilder.run()` is called.

With system insertion order no longer mattering once #1144 is stabilized, there are only a [few places](https://docs.rs/bevy/0.4.0/bevy/app/struct.AppBuilder.html) that rely on ordering (as best as I can tell).

1. Resource and state insertion. These will typically be able to be added in parallel before any other steps. Special `FromResources` resources are the only wrinkle that comes to mind. We can also catch duplicate insertion of the same type, which is a nice correctness-checking feature.
2. Adding stages. Stage ordering is typically defined relative to other stages. We'll need a little tree resolution mechanism to make sure that dependencies are added first, but solving this will be a major win for refactorability (since you won't need to think about this manually).
3. Working with State. These will want to be handled after resources and stages are added.
4. `set_runner`. We should probably just panic if two of these are set at once, rather than overwriting.

**What alternative(s) have you considered?**

Through clean code architecture, you can often define resources in the corresponding plugin, before any other systems are added. This reduces the pain substantially, but relies on consistent code hygiene, and won't work well for resources that are used by multiple plugins.

**Additional context**

Down the road, this approach opens us up to more sophisticated optimizations and analyses, as we'll have access to all of the parts of the `App` before they're processed, rather than only getting a backwards-looking view at best.