Add state-driven entity disabling using a `EnabledInState` component

[alice-i-cecile]

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

When working with complex states, especially for menus, it can be nice to fully preserve the data of various entities while hiding them from the world.

The "despawn when entering / exiting states" behavior in #18818 is useful for full cleanup, but that's not always desirable.

What solution would you like?

Now that we have a Disabled component, we can do better!

Reuse the StateScoped component name, and cause it to disable and enable entities based on the states.

What alternative(s) have you considered?

This is easy to implement in third-party code, but it's a natural complement and a useful pattern to teach and use internally in first-party tools.

Additional context

Discussed in #18818.

[alice-i-cecile]

We should think about how to handle the migration here because we want to reuse the name, but change the semantics.

If it's shipped in 0.17:

• keep StateScoped as a deprecated alias for DespawnOnStateExit
• make a new DisableWhenNotInState component
• then in 0.18, deprecate that and rename

If it's shipped after that, just jump straight to StateScoped.

[benfrankel]

I have these components named VisibleInState(S) and EnabledInState(S) in my crate pyri_state, keeping with the explicit naming without being a mouthful.

[alice-i-cecile]

EnabledInState is perfect, thanks!

VisibleInState causes weird dependency tree issues (bevy_state and bevy_render have no other reason to know about each other), otherwise I'd suggest we add it too.