Add a public API to ArchetypeGeneration/Id

[nicopap]

Objective

• Since [Merged by Bors] - Document and lock down types in bevy_ecs::archetype #6742, It is not possible to build an ArchetypeId from a ArchetypeGeneration
• This was useful to 3rd party crate extending the base bevy ECS capabilities, such as bevy_ecs_dynamic and now bevy_mod_dynamic_query
• Making ArchetypeGeneration opaque this way made it completely useless, and removed the ability to limit archetype updates to a subset of archetypes.
• Making the index method on ArchetypeId private prevented the use of bitfields and other optimized data structure to store sets of archetype ids. (without transmute)

This PR is not a simple reversal of the change. It exposes a different API, rethought to keep the private stuff private and the public stuff less error-prone.

• Add a StartRange<ArchetypeGeneration> Index implementation to Archetypes
• Instead of converting the generation into an index, then creating a ArchetypeId from that index, and indexing Archetypes with it, use directly the old ArchetypeGeneration to get the range of new archetypes.

From careful benchmarking, it seems to also be a performance improvement (~0-5%) on add_archetypes.

---

Changelog

• Added impl Index<RangeFrom<ArchetypeGeneration>> for Archetypes this allows you to get a slice of newly added archetypes since the last recorded generation.
• Added ArchetypeId::index and ArchetypeId::new methods. It should enable 3rd party crates to use the Archetypes API in a meaningful way.

[hymm]

ran the update archetypes benchmark and seeing a small improvement on updating the archetypes, but a small regression on the no_archetypes case

[nicopap]

I'll redo the no_archetypes benchmarks. I had suspicious numbers (40% improvements) but didn't act on it.

[hymm]

It might be worth changing the schedule to single threaded to reduce the noise in the benchmarks

[nicopap]

So I see what's going on:

• Measurements on no_archetypes are between 4 nanoseconds and 35 microseconds (on my machine at least)
• A single instruction on a 4GHz processor runs in 0.25 nanoseconds.
• This means that any noise is going to have an outsized impact on measurement. Not exactly clear how slow are context switches, supposing it is 1000 instructions, if you add that to 1000 samples on no_archetypes/system_count/0, it's one more instruction out of 16, so a 6% slowdown.

I added taskset --pid --cpu-list 0 $PID to make sure there is no CPU switches, and I see no noise or difference between runs of no_archetype benchmarks on my machine.

Though the suggestion of using the single threaded executor seems like a good idea.

More benchmark discussion here https://llvm.org/docs/Benchmarking.html#linux

[atlv24]

appears sensible.