many_components stress test improvements

[hymm]

Objective

• I was getting familiar with the many_components example to test some recent pr's for executor changes and saw some things to improve.

Solution

• Use insert_by_ids instead of insert_by_id. This reduces the number of archetype moves and improves startup times substantially.
• Add a tracing span to base_system. I'm not sure why, but tracing spans weren't showing for this system. I think it's something to do with how pipe system works, but need to investigate more. The approach in this pr is a little better than the default span too, since it allows adding the number of entities queried to the span which is not possible with the default system span.
• println the number of archetype component id's that are created. This is useful since part of the purpose of this stress test is to test how well the use of FixedBitSet scales in the executor.

Testing

• Ran the example with cargo run --example many_components -F trace_tracy 1000000 and connected with tracy
• Timed the time it took to spawn 1 million entities on main (240 s) vs this pr (15 s)

---

Showcase

Future Work

• Currently systems are created with a random set of components and entities are created with a random set of components without any correlation between the randomness. This means that some systems won't match any entities and some entities could not match any systems. It might be better to spawn the entities from the pool of components that match the queries that the systems are using.

[chescock]

Should this be info! so it can be configured with the logging framework?

[hymm]

I'm not sure. I see some examples use info and some use println. This example was using println already, so I just kept it consistent.

[BenjaminBrienen]

Needing unsafe in the benchmarks makes me feel like we could improve the API.

[hymm]

Needing unsafe in the benchmarks makes me feel like we could improve the API.

it's because we're spawning things dynamically, for which I don't think we can avoid unsafe.