Add Allows filter to bypass DefaultQueryFilters

[NiseVoid]

Objective

Fixes #17803

Solution

• Add an Allows<T> QueryFilter that adds archetypal access for T
• Fix access merging to include archetypal from both sides

Testing

• Added a case to the unit test for the application of DefaultQueryFilters

[Carter0]

Is it possible to write or update a test or example explaining why allows is different than has?

[Carter0]

Could use an example, but I think the implementation is good!

[chescock]

I don't think this use of "archetypal" access matches the original intent. (Although I don't know whether anyone is actually using it for its original purpose!)

From #11700,

It would be useful to be able to inspect a QueryState's accesses so we can detect when the data it accesses changes without having to iterate it.

Add the notion of "archetypal" accesses, which are not accessed directly, but whose presence in an archetype affects a query result.

Allows<T> is sort of the opposite, as it means T no longer affects the query result, even though it does by default on other queries.

I'd gently vote for making this a new kind of access. If we do want to use "archetypal" for this, then we should probably update the doc comment to say something other than "whose presence in an archetype may affect query results".

[alice-i-cecile]

I'd gently vote for making this a new kind of access. If we do want to use "archetypal" for this, then we should probably update the doc comment to say something other than "whose presence in an archetype may affect query results".

I'm sympathetic to this, but I'm reluctant to block this particular PR over it, or to add more complexity for a very niche feature currently.