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

States in bevy_ecs can and should be implemented freely by consumers: many possible variations exist (pattern matching, substates, state stacks).

By including them within bevy_ecs, we:

1. Risk introducing internal coupling by relying on crate-private APIs.
2. Suggest to end users that they can't and shouldn't write their own alternatives.
3. Clutter bevy_ecs, increasing complexity and compile times for both users and maintainers.

What solution would you like?

Move States into their own bevy_state crate.

What alternative(s) have you considered?

Leave it as is.

Additional context

[8:37 PM]Joy: the main opinion I really have on states atm is they should be moved to their own crate
Comment by @maniwani