Optimize table-only component queries with sparse set filters

[alice-i-cecile]

Sparse set components are most commonly used as simple unit struct marker components, so will show up a lot in query filters.

table iteration can (currently) only be used when the query only contains table components (this includes filters). if you add a sparse component/filter, the query will switch to "archetype iteration".
"hybrid queries" will still be faster than "full sparse set" queries, but they are still "archetype iterators"
the reason we can't use table iteration for "sparse filters" is that the With / Without information isn't stored in Tables (its in Archetypes). There is a 1->many relationship between tables and archetypes (each row of a table might belong to a different archetype).
Some of the items in the table might match the query filter, others might not
whereas we can make that guarantee when the filters are table-only
as we can just check to see if the table has that component type
there is a world where we enable storing archetype information in table rows to accelerate sparse filters
or alternatively, allocating blocks in tables for a given archetype
eh maybe not the second one
otherwise we're back to square one when it comes to "add/remove operation costs"

• explanation by @cart

From Discord.

[alice-i-cecile]

Duplicate of #2144.