Component Lifecycle Query Filters

[xentripetal]

It would be very helpful if query descriptions had support for defining filters based on the lifecycle of components.

Mainly:

1. Added<T> - Evaluates to true when component T was added to an entity since the last execution of the query
2. Removed<T> - Evaluates to true when component T was removed from an entity since the last execution of the query
3. Changed<T> - Evaluates to true when component T was accessed mutably or set for the entity since the last execution of the query

This is a feature present in bevy_ecs (Rust), DefaultECS (C#), and Unity DOTS

I'm not sure how feasible this is with Arch's architecture, but figured I'd put the idea out there since I'd love to see it in Arch.

This would be a massively useful feature for the non-ecs code that needs to interact with the entities, allowing to decouple said non-ecs code from the main update loop.

A few scenarios:

• Spawning a new entity from network activity, for example: network component creates a lightweight ‘NerworkHandler’ component and the rest of the ecs finishes the spawning by attaching necessary components to fully initialise it from game rules specified in the ecs.

• An ad-hog event handling system, where components could be added to indicate an event and handled by a system, though I’m not quite sure if this is a good way to do this.

[JoNax97]

#291 aims to address the changed part

[studentutu]

Would be much better if Arch ECS would simply have a DirtyFlags component/internal attribute to Entity itself and query internally used it instead of a signature change.
This is much more scalable, and something similar is used in Entitas and in custom ECS frameworks in order to improve readability and allow quick changes to the entity without moving it into a different archetype.
@genaray this is something that makes Arch ECS unusable in current production, and that is the main reason people switch to Entitas or other ECS frameworks. We don't need bloated ECS; we need a stable, reliable, and consumer-driven one, meaning systems and code are easily extendable even for cases where there are only a few entities.

Here is a concrete example:

        [Test]
        public void CreateEntity_FromSignature_CheckMarker()
        {
            // Issue: we can't simplify systems as Arch-ecs markers are build into entity archetype
            // - thus when adding/removing components from entity, Arch-ecs fully moves it between archetypes! (very expensive)
            // In order to avoid it: we must use separate slim entity-requests.
            var CharacterSignatureWithMarker = new Signature(typeof(SimId), typeof(CharacterStats), typeof(CharacterScaling),
                typeof(CharacterSkillbook), typeof(CharacterSpawnRequest));

            var entity = _world.Create(CharacterSignatureWithMarker);

            var archEcsHasMarkerByDefault = entity.Has<CharacterSpawnRequest>();
            Assert.IsTrue(archEcsHasMarkerByDefault); // should be false! and only when we really add CharacterSpawnRequest it will be true
        }