Refactor state management to use StateScoped instead of explicit cleanup

[ShenMian]

Replace explicit cleanup systems with StateScoped components to manage state transitions more efficiently.
This change simplifies the plugin systems by removing the need for dedicated cleanup systems for some scenes.

[rparrett]

I'm slightly conflicted by this, because now we have two different ways of doing state-related entity cleanup in the project.

But shiny new Bevy features are fun, and deleting code is fun.

Thanks!

[ShenMian]

@rparrett This is true, but I've found that the spawn and despawn of other entities (such as Enemy) are not strictly limited to one state.

For example, the following code has two states:

entytd/src/enemy.rs

Lines 24 to 29 in 9d647ff

	.add_systems(
	Update,
	(spawn, pathfinding, behavior, tick_cooldown, attack, die)
	.run_if(in_state(GameState::Playing)),
	)
	.add_systems(OnExit(GameState::GameOver), cleanup::<Enemy>);

If they can be clearly limited to one scene, they can be managed uniformly using StateScoped:

entytd/src/main_menu.rs

Lines 20 to 37 in 3dbe165

	.add_systems(OnEnter(GameState::MainMenu), (setup_menu, init_background))
	.add_systems(
	Update,
	(
	sfx_volume,
	music_volume,
	play_button,
	sfx_button,
	music_button,
	difficulty_button,
	particles_button,
	)
	.run_if(in_state(GameState::MainMenu)),
	)
	.add_systems(
	OnExit(GameState::MainMenu),
	(crate::util::cleanup::<MainMenuScene>, cleanup_background),
	);

I am not clear about the various possibilities of scene switching, so I kept some old code.

[rparrett]

Yep! I saw that this couldn't be used directly in the other places where cleanup is used, and I'm okay with it for now.

Maybe the game states could be rearranged to make that work, but that sort of refactor doesn't sound fun to me right now :).