Better entities tracking issue

[ElliottjPierce]

Objective

I've been deep in Bevy's entity code for a few weeks now, working on remote entity reservation. Having become pretty familiar with it, there's a few areas I think we can significantly improve.

This is a tracking issues for my ideas here. Each one deserves discussion, but since they are separate issues, I figured a tracking issue would be better than a discussion post with disjoint comments.

Roadmap

• Remove old alloc_at functionality. Remove insert_or_spawn function family #18148 . This was a performance foot gun for users and it made Entities overly restrictive.
• Properly handle u32::MAX index entity. Right now, this is a bug in Entities. One solution is out here: Make entity::index non max #18704 . (But that's still up for debate).
• Make generations u32 in a new type. Make entity generation a new type and remove identifier #19121
• Make TableRow, ArchetypeRow, etc non-max. Nonmax all rows #19132
• Implement remote entity reservation. Remote entity reservation v9 #18670 is a clear winner for this IMO. It has better performance than main while offering a much more flexible interface.
• Allow bulk freeing.
• Try to remove atomics in remote reservation slots
• Explore adding back insert_or_spawn_batch. See here.
• Speed up Command entity spawning.
• Remove internal use of untyped u32s as entity generation and index. We have types for these now!
• Implement iterator for EntityGeneration. Implement iterator for entity generation #19144
• Rename some functions in the entity module. These have strayed a bit from their best meaning, but haven't been updated to prevent a migration guide. But I think it's worth it.
• Remove the Identifier system. This is an ecs utility that is only used by Entity. But these changes make Entity pretty unique as far as identifiers go, and given that the identifier system is only used by entities, I think we can safely let this go to reduce complexity.
• Remove/deprecate Entity::PLACEHOLDER. The only possible reason to use this is as a replacement for MaybeUninit:: uninit that trades UB fort a logic error. But who's doing that? Option is better anyway for most things, and people can make their own placeholders if needed. That would make the risks more explicit.
• After allowing archetypes and tables to be unregistered, make TableId and ArchetypeId non max. If there can't be u32::MAX entities, there cant't be that many archetypes. Let's give it a niche for the places this is used in an option.
• Make ComponentId wrap entity information. This is the first step in components as entities.
• Create a custom ComponentId map that is an optimized HashMap<ComponentId, T>. This would be a vec index for the first SOME_CONSTANT entities and then a hashmap after that.
• Create a public interface for creating custom entity allocators. This should be easy to support and would let people make allocators for grouping dense entity ids, etc.
• Allow entity ids to be reserved by default for components as entities.