Add PreviousState Resource accessible in OnEnter

[Br3nnabee]

Objective

• Adds a PreviousState resource to track the last active state, making it accessible during state transitions (e.g., in OnEnter schedules).
• Fixes A PreviousState Resource, accessible in OnEnter #21882.

Solution

• Added a new PreviousState<S: States> resource.
• Updated internal_apply_state_transition to manage the lifecycle of PreviousState:
  • Standard Transition: Updates PreviousState to the exited state.
  • Creation: If a state is initialized (transition from None), any existing PreviousState is removed.
  • Removal: If a state is removed, PreviousState is updated to preserve the last known state.
• Registered PreviousState in AppExtStates for reflection and general access.
• Ensured PreviousState is available for OnEnter systems by using ApplyDeferred ordering in setup_state_transitions_in_world.

Testing

• Added a temporary local unit test previous_state_is_tracked_correctly which verifies that PreviousState is created, updated, and persisted correctly across multiple state transitions.
• The implementation covered scenarios including standard transitions, state initialization (where no previous state exists), and state removal.
• Don't think I handled all edge cases, would appreciate a second look.

---

Showcase

You can now access the state you just transitioned from directly in your systems!

fn handle_state_refresh<S: FreelyMutableState>(
    prev_state: Option<Res<PreviousState<S>>>, 
    mut next_state: ResMut<NextState<S>>
) {
    if let Some(prev) = prev_state {
        println!("We just came from {:?}", prev.0);
        // Example: revert to previous state
        next_state.set(prev.0.clone());
    }
}

app.add_systems(OnEnter(GameState::Refresh), handle_state_refresh::<GameState>);

_{This is my first contribution, would highly appreciate some feedback!}

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[kfc35]

Thanks for your first contribution, and welcome! (Coming from a fellow new-ish contributor)

It looks good to me logic wise, but I defer to someone else to make doubly sure since I’m relatively inexperienced with the state code.

I wonder if this change is worth 1) a release note and 2) an update to the states.rs example to show how one can now read the PreviousState as a resource. The example update could be a candidate for a follow up if desired?

[pablo-lua]

The logic is good, good work and thanks for the change. We probably could remove that ApplyDeferred though

[alice-i-cecile]

The ApplyDeferred needs to be removed, then this LGTM :)

[Br3nnabee]

Alright, so I've removed the ApplyDeferred section now. There's a merge conflict due to #21792, but as far as I see it's a quick fix. Should I be the one to handle that, or would you prefer to?

[alice-i-cecile]

Yes please; handling merge conflicts is done by authors around here :)

[mockersf]

Should it be possible to disable this? It's keeping an extra clone in memory of the state when not everyone needs it

[LikeLakers2]

@mockersf I wouldn't bother - unless you have many states using tens of megabytes each (at which point, you already need to do some optimizing), it's not going to use much extra memory.

That said, if you can find a way to let people opt-in to this on a per-state basis without much extra work, I wouldn't complain.

[mockersf]

We put no limit on the size of the state, and it's not Copy, so we should not presume too much of how it will be used

[LikeLakers2]

@mockersf Yet the hit (in terms of CPU usage and memory usage) is unlikely to be noticed by the end user, unless their state is quite large and complicated, or they are running quite slow hardware.

That said, if this "previous state" stuff could be moved to a wrapper that allows opting in on a per-case basis, then I wouldn't complain.

[pablo-lua]

@mockersf Yet the hit (in terms of CPU usage and memory usage) is unlikely to be noticed by the end user, unless their state is quite large and complicated, or they are running quite slow hardware.

That said, if this "previous state" stuff could be moved to a wrapper that allows opting in on a per-case basis, then I wouldn't complain.

I think you can do just that by letting the user insert the resource (would need to change how this pr is now) if they want to use it or by feature flagging (would need to change a little of this pr, probably).