New `Entity` allocation paradigm

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:

- [x] Make `EntityMeta` use `Option`.
- [x] Decouple spawning from setting entity location.
- [x] Implement entity constructing and destructing.
- [x] Remove entity reservation and flushing and all uses of it. (We can accomplish the same things faster through constructing.)
- [x] 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.
- [x] 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.