Add mappings to EntityMapper

[bushrat011899]

Objective

• Fixes Provide entities_iter() on EntityMapper to get an iterator of foreign entities #13703

Solution

• Added mappings to the EntityMapper trait, which returns an iterator over currently tracked Entity to Entity mappings.
• Added DynEntityMapper as an object safe alternative to EntityMapper.
• Added assert_object_safe as a helper for ensuring traits are object safe.

Testing

• Added new unit test entity_mapper_iteration which tests the SceneEntityMapper implementation of EntityMapper::mappings.
• Added unit tests to ensure DynEntityMapper, DynEq and DynHash are object safe.
• Passed CI on my Windows 10 development environment

---

Changelog

• Added mappings to EntityMapper trait.

Migration Guide

• If you are implementing EntityMapper yourself, you can use the below as a stub implementation:

fn mappings(&self) -> impl Iterator<Item = (Entity, Entity)> {
    unimplemented!()
}

• If you were using EntityMapper as a trait object (dyn EntityMapper), instead use dyn DynEntityMapper and its associated methods.

Notes

• The original issue proposed returning a Vec from EntityMapper instead of an impl Iterator to preserve its object safety. This is a simpler option, but also forces an allocation where it isn't strictly needed. I've opted for this split into DynEntityMapper and EntityMapper as it's been done several times across Bevy already, and provides maximum flexibility to users.
• assert_object_safe is an empty function, since the assertion actually happens once you try to use a dyn T for some trait T. I have still added this function to clearly document what object safety is within Bevy, and to create a standard way to communicate that a given trait must be object safe.
• Other traits should have tests added to ensure object safety, but I've left those off to avoid cluttering this PR further.

[alice-i-cecile]

Neat, the assert_object_safe tests and the Dyn trait variants are compelling. I think I like this solution overall: this is perf-sensitive code so the complexity is worth it.

Definitely more complicated than Trivial though: I tend to reserve that for "could someone that's never written Rust review this PR" :)