Rewrite part of Commands rustdoc

[stepancheg]

• Explain it is flushed in the same schedule run (was not obvious to me)
• Point to apply_deferred example
• Remove mentions of System::apply_deferred and Schedule::apply_deferred which are probably too low level for the most users

[hymm]

With #9822 merged the story here is a little more complex now.

[stepancheg]

Suggestions how to rephrase it?

I submit PRs to rustdoc comments, when I'm trying to understand something, and apparently I don't always understand it correctly.

Also that PR says:

This PR auto inserts sync points if there are deferred buffers on a system and there are dependents on that system (systems with after relationships).

Doesn't it mean that apply_deferred example is outdated — apply_deferred call is no longer needed here?

bevy/examples/ecs/apply_deferred.rs

Lines 22 to 29 in 8067e46

	(
	despawn_old_and_spawn_new_fruits,
	// We encourage adding apply_deferred to a custom set
	// to improve diagnostics. This is optional, but useful when debugging!
	apply_deferred.in_set(CustomFlush),
	count_apple,
	)
	.chain(),

[hymm]

Doesn't it mean that apply_deferred example is outdated — apply_deferred call is no longer needed here?

Yeah probably. You can still add apply_deferred manually and the algorithm will respect it, but the algo doesn't merge manually added sync points together only the auto added ones. For that reason I would not recommend not adding sync points in manually. For the example it might make sense to make a new schedule that disables auto inserted sync points. That or just delete it. That should be done in a separate PR of course.

[hymm]

Suggestions how to rephrase it?

I think the main point of emphasis should be that it's enough to add a before/after relationship between the systems for them to see the effect of commands.

[stepancheg]

Changed the docs — added dependencies between systems, and moved it to apply_deferred.