Rewrote concurrent entity allocations to be more efficient

[mjhostet]

This makes several changes:

• Cuts in half the number of atomic operations to reserve an Entity,
  and simplifies the reservation code to no longer need a retry loop.
• Adds a new reserve_entities method that can reserve any number
  of Entity IDs with a single atomic subtract.
• Removed the reserved and free arrays, which consumed
  two u32 values for every Entity ID, and replaced them with a single
  pending Vec. pending only needs one slot for every freed Entity.
• No longer dump huge lists of fresh IDs into the freelist when we
  grow. The freelist only holds explicitly freed values, and we use
  arithmetic to acquire new IDs.
• Removes the reserved_len(), etc. API used to flush reserved
  entities. Now flush() takes a closure to initialize each entity.
• Tightened the restrictions on what you are allowed to do while you
  have unflushed reservations.
• Grow meta and pending incrementally, as values are allocated and
  freed, rather than in a monolithic grow method. This turns out
  to make things simpler, e.g. we need to track the end of the
  "reserved" range of pending anyway, and using the Vec len is handy.
• Adds some unit tests.

[mjhostet]

I assume that contains returning true for out of range IDs was a typo, and not intentionally trying to return true for reserved IDs. But if I'm wrong let me know.

[Ralith]

Thanks for the PR! Will try to dig into it this week.

I assume that contains returning true for out of range IDs was a typo, and not intentionally trying to return true for reserved IDs. But if I'm wrong let me know.

This was actually intended behavior. The principle is that sensible results are only guaranteed for Entity IDs that were legitimately obtained from the same world, and for those, the only possible way to end up with an out-of-range entity is by reserving it and not flushing the world after, therefore they're necessarily live. I'm trying to minimize the differences between a reserved entity and a conventionally spawned empty entity, at least short of showing up in queries.

[Ralith]

Did a deep dive. This looks awesome, thanks! Only cosmetic issues, AFAICT.

[Ralith]

Style nit: This would be a little more concise if Ranges were computed directly without the start/end intermediate variables. For example:

let freelist_range = range_start.max(0) as usize .. range_end.max(0) as usize;

[mjhostet]

Thanks, I applied all of your feedback.

[Ralith]

Great stuff!