feat(engine): Archetype garbage collection

[0ffz]

Our use of relations and events means at all times, there are far more archetypes than entities, somewhat defeating the purpose of an archetypal ECS.

No archetypes

• Ditch archetypes altogether and store data in individual entity arrays. Lookup stays the same, adding and removing components becomes slower, bottlenecked by tracking which systems should act upon this entity. Will depend on #67
• We don't really have the ability to tightly pack data anyways (we want to support adding arbitrary objects to entities), so cache misses when iterating are already inevitable
• Less garbage generated as there are never any remnants to clean up

Archetypes as a temporary cache

• Focus on archetypes as a caching layer for system matching and helper for the case of many many of an identical entity
• Empty archetypes can be cleared after they become unused for long enough
• This puts more strain on the garbage collector, and extra overhead for a system that clears out old archetypes
• Realistically archetypes that don't get used often shouldn't contain much data anyways (ex the ids array won't grow big), though more thought should be put into immediately clearing unused archetypes when they empty or keeping them longer

Archetypes as a permanent cache

• Do nothing, or be extremely lenient with how things get cleaned. Benchmark how much memory we really use and treat the entire archetype tree as a slowly built cache (when an app runs for long enough, it could be that it generates pretty much every possible archetype it will need, so storing them all becomes worth it)

[0ffz]

Pretty much the Archetypes as a temporary cache idea was implemented a while back to remove empty archetypes by default, optionally letting you mark archetypes to keep.

I'm questioning whether the extra code to maintain is worth it especially if we ever get archetypes to hold multiple added component types (i.e. only batching components with data) since this would solve the overhead with relations.