Avoid iterating through all the entities

[kvark]

In a lot of cases, the fraction of entities that do need to be processed is just a fraction of all entities. We lose a lot of time by checking all the entity components to exist. This information could be cached and re-used.

We could get a small speedup (in general) by early exiting if one of the components is not found. Similarly, we could advice users to convert problematic runXwYr calls to custom run calls and early-exit manually.

As a last resort, one could separate the ECS into two, so that the component coverage is denser in each (like, don't mix particle entities with UI entities with game entities, etc).

One way to properly address this is to use tables. @csherratt reported the speedup from ~260us to ~50us by building on top of our Storage interface.

Another way would be to have Aspect as a special construct that tracks which entities have a required set of components, proposed by @OvermindDL1.

[OvermindDL1]

For note, my 'Aspects' only defined where they looked in the Aspect cache. If someone in my system creates an Aspect.match<HealthComponent, DamageComponent>, Aspect.optional>() it just returns a single pointer into the aspect cache, the cache itself was a recursive map of maps with keys of component atoms/ids and values of the matched ones with sub-matches with other components requested. You 'should' create any Aspects as early as possible as the first time a certain matchspec is defined it will iterate over all entities to see which go in, but from then on that cache is kept up to date among all aspects that match on the same matchspec.

The old system I based the style off of (Artemis, don't bother looking at it, this was the only good part about its system) used each Aspect as its own cache and they just registered event handlers to hear when components were added/removed, which caused more indirect function calls compared to mine.

Plus duplicated data

[OvermindDL1]

I just looked in the Tables library a bit more (I still have so much more to learn about rust syntax, I have the ideas, but just the syntax... >.>), looks like it would work very well as a backing store while also using Aspects, they are not competing concepts but rather seem to attack two different issues in their own efficient ways. Perhaps they should both be integrated.

[kvark]

Fixed by #29