Make standard commands more ergonomic (in niche cases)

[RobWalt]

Objective

I ran into a case where I need to create a CommandQueue and push standard Command actions like Insert or Remove to it manually. I saw that Remove looked as follows:

struct Remove<T> {
  entity: Entity,
  phantom: PhantomData<T>
}

so naturally, I tried to use Remove::<Foo>::from(entity) but it didn't exist. We need to specify the PhantomData explicitly when creating this command action. The same goes for RemoveResource and InitResource

Solution

This PR implements the following:

• From<Entity> for Remove<T>
• Default for RemoveResource and InitResource
• use these traits in the implementation of methods of Commands
• rename phantom field on the structs above to _phantom to have a more uniform field naming scheme for the command actions

---

Changelog

This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.

• Added: implemented From<Entity> for Remove<T> and Default for RemoveResource and InitResource for ergonomics

[github-actions]

Welcome, new contributor!

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

[alice-i-cecile]

This is marginally nicer, but definitely a niche bit of the API. On the fence if the complexity here is worth it.

Could we make constructor methods instead? I think that's a better spot on the complexity <-> ergonomics curve for a niche API.

[RobWalt]

Not a big fan of From impls in generals, so I'm really glad you asked!

[RobWalt]

I was a bit too hasty there 😅 Good catches! Thanks!

[alice-i-cecile]

Oh right: this is also technically breaking because you renamed the phantom data field. I'd probably just revert that? I don't think it's appreciably better.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.