Add set_state extension method to Commands

[UkoeHB]

Objective

• Improve the ergonomics of managing states.

Solution

• Add set_state extension method to Commands so you don't need to type out ResMut<NextState<S>> to update a state. It also reduces system parameter list size when you already have Commands.
• I only updated a couple examples to showcase how it can be used. There is a potential perf cost to introducing Commands so this method shouldn't necessarily be used everywhere.

Testing

• Tested the updated examples: game_menu and alien_cake_addict.

---

Showcase

Add Commands::set_state method for easily updating states.

Set directly:

fn go_to_game(mut game_state: ResMut<NextState<GameState>>) {
    game_state.set(GameState::Play);
}

Set with commands (NEW):

fn go_to_game(mut commands: Commands) {
    commands.set_state(GameState::Play);
}

[TrialDragon]

I've tested the examples that were changed, they still work. I feel it is adequately documented, and I personally like the API ergonomics of being able to just use commands to set state, whilst still having the direct setting for performance use cases. LGTM.

[alice-i-cecile]

I'm on board with this as a convenience API (and the flexible nature of it is genuinely useful), but I'd like to revert the changes to the examples. We should teach users a single, consistent way to use our APIs, and default to the clearer and more performant existing API.

[MiniaczQ]

I don't think we need to worry about command overhead, state switching is a pretty heavy operation just because of the transitions involved.

[MiniaczQ]

Second thoughts, I'd like this to be the standard way of updating states.
Using commands:

• implies the deferred nature of this operation
• reduces clutter associated with NextState, especially when many are used
• does not make problems with system ambiguities worse
• allows for falliable operations with a warning, which we will need when the traits get unified and not everything will use NextState
• with a different command you can force the transition to happen immediately without writing an exclusive system

@alice-i-cecile what do you think?
I don't think this change has to happen now, but it looks like a better API overall to me

[Shatur]

I'm on board with @MiniaczQ, I would even remove the NextState method.