Add missing unsafe to entity_command::insert_by_id and make it more configurable

[JaySpruce]

Objective

insert_by_id is unsafe, but I forgot to add that to the manually-queueable version in entity_command.

It also can only insert using InsertMode::Replace, when it could easily be configurable by threading an InsertMode parameter to the final BundleInserter::insert call.

Solution

• Add unsafe and safety comment.
• Add InsertMode parameter to entity_command::insert_by_id, EntityWorldMut::insert_by_id_with_caller, and EntityWorldMut::insert_dynamic_bundle.
• Add InsertMode parameter to entity_command::insert and remove entity_command::insert_if_new, for consistency with the other manually-queued insertion commands.

[chescock]

Elsewhere the pub methods seem to use insert for InsertMode::Replace and insert_if_new for InsertMode::Keep. Should we add insert_by_id_if_new instead of adding a mode parameter, for consistency?

[JaySpruce]

It's sort of already inconsistent, since entity_command::insert_from_world and command::insert_batch have a parameter instead of another method. I wouldn't really mind either way, but that sort of combinatorial API explosion can be contentious

[chescock]

Sounds good! I do prefer the parameter approach to avoid the combinatorial API explosion, I just also like consistency :).

Would it be worth creating a follow-up issue to remove insert_if_new in favor of an InsertMode parameter on insert?

[JaySpruce]

I briefly did that as part of this PR before I changed my mind lol. I could re-add that here, or make another PR if you think it's a big enough change or too unrelated

[chescock]

I was wondering if we even wanted to change the already-released EntityCommands::insert_if_new, and we wouldn't want to block a soundness fix with a debate about that. The functions in this file are new in this release, though, so if you're just changing these then I'm happy either way!