Split States into their own crate, and add convenience app extension methods

[alice-i-cecile]

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

Bevy states are well-isolated from other app or ECS logic, and not all users will want to use our exact implementation (e.g. some users may want a state stack).

Adding dedicated methods to manage and work with states to both bevy_app and bevy_ecs feels "wrong" as a result: it ends up polluting APIs with what could reasonably be an add-on.

What solution would you like?

1. Create a new bevy_states crate.
2. Move all core state logic out of bevy_ecs.
3. Move App::add_state out of bevy_app onto an extension trait.
4. Add .on_update, .on_enter and .on_exit system modifiers via an extension trait.
5. Depend on bevy_states in bevy_core as an optional dependency and add the extension traits and structs back to the prelude.

What alternative(s) have you considered?

If we want to replace startup systems with states as in #5437, we should be able to retain this design, and simply import bevy_states in bevy_core.

Additional context

This was proposed by @maniwani in #7790 here, which attempted to add sugar for on_update.

#7634 is also something to be mindful of during the implementation.

[swfsql]

Hi, I've started learning Bevy a couple of days ago, and the state update was very welcome!
Just today I've been trying out some ergonomics builder, link to an example.

I'll be looking forward to the development, and thanks for your work!

[alice-i-cecile]

Fixed by #13216