Restore support for running fn EntityCommands on entities that might be despawned

[joseph-gio]

Objective

In #9604 we removed the ability to define an EntityCommand as fn(Entity, &mut World). However I have since realized that fn(Entity, &mut World) is an incredibly expressive and powerful way to define a command for an entity that may or may not exist (fn(EntityWorldMut) only works on entities that are alive).

Solution

Support EntityCommands in the style of fn(Entity, &mut World), as well as fn(EntityWorldMut). Use a marker generic on the EntityCommand trait to allow multiple impls.

The second commit in this PR replaces all of the internal command definitions with ones using fn definitions. This is mostly just to show off how expressive this style of command is -- we can revert this commit if we'd rather avoid breaking changes.

---

Changelog

Re-added support for expressively defining an EntityCommand as a function that takes Entity, &mut World.

Migration Guide

All Command types in bevy_ecs, such as Spawn, SpawnBatch, Insert, etc., have been made private. Use the equivalent methods on Commands or EntityCommands instead.

If you were working with ChildBuilder, recreate these commands using a closure. For example, you might migrate a Command to insert components like:

// Before (0.12)
parent.add_command(Insert {
    entity: ent_text,
    bundle: Capitalizable,
});

// After (0.13)
parent.add_command(move |world: &mut World| {
    world.entity_mut(ent_text).insert(Capitalizable);
});

[hymm]

What effect does using a closure for commands have here? Each instance of a closure is a unique type, but I'm not sure I understand how that would effect the performance or the amount of code generated.

[joseph-gio]

The closures shouldn't affect anything. They're just turning an explicit unique type into a hidden unique type.

[hymm]

ran some benches and seems like if there's any diff it's within the noise.

[alice-i-cecile]

I really like these changes. The reduced boilerplate is excellent.

IMO just completely removing things like the SpawnBatch struct from our public API is a net win: these were confusing and never used in practice.