New `Entity` allocation paradigm

[ElliottjPierce]

This is both building on and an alternative to much of my better entities ideas: #18719. I was inspired from talking with Sander about flecs entities. Flecs does something special with its ids: it pages them into chunks. This lets the id range be broken up more and is extremely powerful for various kinds of allocations.

For a while, I wasn't sure if this was right for bevy. The UX seemed more complicated, etc, but I think I've come up with a way to do this in a pure, efficient, and user friendly way. I think this will be roughly 2x faster than my remote reservation v9 pr #18670 while giving tons more flexibility to users.

Some things this will allow users to do:

• Hold onto Entity ids without freeing them, so as to World::construct and World::destruct them instead of spawn and despawn. This will be a more powerful version of the old Entities::alloc_at idea for power users (which has been requested).
• Create custom entity allocators that upholds certain properties. Ex: could allocate ranges of consecutive entities, which I've heard is useful for tile maps and is already necessary for components as entities.
• Create server authoritative allocators so client and server share entity ids.
• Benefit from performance improvements to both local and remote allocators.

Here's a rough roadmap for how to get there:

• Make EntityMeta use Option<EntityLocation>.
• Decouple spawning from setting entity location.
• Implement entity constructing and destructing.
• Remove entity reservation and flushing and all uses of it. (We can accomplish the same things faster through constructing.)
• Pull entity allocation out of Entities. Entities will be a database of EntityMeta, separate from allocations.
• Implement a EntityIndex map data structure.
• Page EntityIndex. This changes map[index] to map[page_index][inner_index], which we know from flecs is well worth it!
• Generalize entity allocators.
• Create a remote allocator.

As you go further down the roadmap, the tasks get maybe more controversial, so we can stop an any point. But if we do do all of them, I think the result would be incredible. We'd have an extremely flexible api, simple, but very powerful when needed. "Special" entity allocation, like what we need for assets as entities or components as entities becomes attainable and simple for users who need it, etc.

Because each of these tasks are still valuable independently, I'll save more details for individual prs.

[re0312]

I am a fan of this paradigm, looks like it could also solve the problem of inconsistent entity ID between the render world and main world. Additionally, before paging the EntityIndex, we should migrate our component sparse set implementation to a paged sparse set to prevent memory hole.