Stop using ArchetypeComponentId in the executor

[chescock]

Objective

Stop using ArchetypeComponentId in the executor. These IDs will grow even more quickly with relations, and the size may start to degrade performance.

Solution

Have systems expose their FilteredAccessSet<ComponentId>, and have the executor use that to determine which systems conflict. This can be determined statically, so determine all conflicts during initialization and only perform bit tests when running.

Testing

I ran many_foxes and didn't see any performance changes. It's probably worth testing this with a wider range of realistic schedules to see whether the reduced concurrency has a cost in practice, but I don't know what sort of test cases to use.

Migration Guide

The schedule will now prevent systems from running in parallel if there could be an archetype that they conflict on, even if there aren't actually any. For example, these systems will now conflict even if no entity has both Player and Enemy components:

fn player_system(query: Query<(&mut Transform, &Player)>) {}
fn enemy_system(query: Query<(&mut Transform, &Enemy)>) {}

To allow them to run in parallel, use Without filters, just as you would to allow both queries in a single system:

// Either one of these changes alone would be enough
fn player_system(query: Query<(&mut Transform, &Player), Without<Enemy>>) {}
fn enemy_system(query: Query<(&mut Transform, &Enemy), Without<Player>>) {}

[alice-i-cecile]

Ah, so we're moving from factual to hypothetical conflicts here. Interesting. I think that this is the right direction, to reduce pain with relations, and also to allow us to precompute more about the schedule ordering ahead of time in the future.