Allow disjoint mutable world access via EntityMut

[JoJoJet]

Objective

Fix #4278
Fix #5504
Fix #9422

Provide safe ways to borrow an entire entity, while allowing disjoint mutable access. EntityRef and EntityMut are not suitable for this, since they provide access to the entire world -- they are just helper types for working with &World/&mut World.

This has potential uses for reflection and serialization

Solution

Remove EntityRef::world, which allows it to soundly be used within queries.

EntityMut no longer supports structural world mutations, which allows multiple instances of it to exist for different entities at once. Structural world mutations are performed using the new type EntityWorldMut.

fn disjoint_system(
     q2: Query<&mut A>,
     q1: Query<EntityMut, Without<A>>,
) { ... }

let [entity1, entity2] = world.many_entities_mut([id1, id2]);
*entity1.get_mut::<T>().unwrap() = *entity2.get().unwrap();

for entity in world.iter_entities_mut() {
    ...
}

---

Changelog

• Removed EntityRef::world, to fix a soundness issue with queries.

• Removed the ability to structurally mutate the world using EntityMut, which allows it to be used in queries.
• Added EntityWorldMut, which is used to perform structural mutations that are no longer allowed using EntityMut.

Migration Guide

Note for maintainers: ensure that the guide for #9604 is updated accordingly.

Removed the method EntityRef::world, to fix a soundness issue with queries. If you need access to &World while using an EntityRef, consider passing the world as a separate parameter.

EntityMut can no longer perform 'structural' world mutations, such as adding or removing components, or despawning the entity. Additionally, EntityMut::world, EntityMut::world_mut , and EntityMut::world_scope have been removed.
Instead, use the newly-added type EntityWorldMut, which is a helper type for working with &mut World.

[iiYese]

I mostly left it because EntityRef::world is mildly useful sometimes

I would like identified cases of when. The API duplication is getting ridiculous now

• &mut World
• Commands
• EntityCommands
• EntityRef
• EntityMut
• EntityBorrow
• EntityBorrowMut

Should try not to bloat this further until refactors on the horizon are possible. If no good argument can be made for or against keeping EntityRef then a push for its removal should be made to find one.

[JoJoJet]

I mostly left it because EntityRef::world is mildly useful sometimes

I would like identified cases of when.

I like to think of EntityRef as a performance-optimized (Entity, &World) tuple, which can be useful any time you're working with direct world access (I have used it for this before). If we removed EntityRef::world, then a bunch of users would have to change some method signatures from fn(EntityRef) to fn(EntityRef, &World) -- not the biggest loss but still annoying.

That said, I'm open to doing it if we decide it's a good idea. I think the path with the least API breakages would be to remove EntityRef, and rename EntityBorrow -> EntityRef. This would open the question of what to call EntityBorrowMut, which would seem out of place without a corresponding EntityBorrow.

[JoJoJet]

I've added some unit tests that are known to fail due to limitations in our current access model. Since the issue is with overly restrictive accesses, it will not cause undefined behavior, so I think it is okay to fix this issue later. Also, note that this issue already existed on the main branch with EntityRef queries.

[JoJoJet]

I have merged EntityBorrow into EntityRef, and removed EntityRef::world.

[JoJoJet]

I have also renamed EntityMut to EntityWorldMut, and renamed EntityBorrowMut to EntityMut. Since I've made so many changes, I've updated the PR description to give an overview of the current state of this PR.

[maniwani]

This looks good to me. I mostly wanted to make sure the access is sound.

I think renaming the existing types is a little strange, but ig it's better for queries to get the types with shorter names. It's fine if there's some type duplication between "queried" and "direct-world" access though. We may find a need for an EntityWorldRef later.

[alice-i-cecile]

I think there are subtle merge conflicts here @JoJoJet; can you rebase and verify things work locally?