Make logical AND explicit in filters with an `And<(..)>` combinator

[iiYese]

What problem does this solve or what need does it fill?

The usage of (..) in query filters is inconsistent with the usage of (..) everywhere else in bevy. In other APIs like Bundle, WorldQuery, IntoSystemConfigs, IntoSystemSetConfigs etc. tuples are just a means to express variadics which rust lacks at the moment. They do not have special meaning on their own.

What solution would you like?

Add an explicit And<(..)> combinator and make the meaning of tuples in filters be consistent with the meaning of tuples elsewhere in bevy.

Additional context

Any time any changes need to be made to filters there seems to be inevitable boolean algebra bike shedding because of this inconsistency like in #9255. This is always because people come in with different mixed notions of what (..) means which is either:

• Var args. Using tuples to work around rust lacking variadic generics. Informed by the encounters of (..) outside query filters in the mentioned APIs.
• Logical AND. Using tuples to implicitly mean logical AND. Informed by what is currently uniquely the status quo for query filters.

Decoupling these and making distinct mechanisms for each stops this pattern from occurring.

[SkiFire13]

I would argue that most do express an "and", although kinda implicit and not always logical:

• WorldQuery: using a tuple will make the query match only when the first nested query matches and the second nested query matches etc etc, and will fetch the value of the first nested query and the value of the second nested query etc etc
• Bundle: using a tuple will insert/remove the components in the first nested bundle and the second nested etc etc
• IntoSystemConfigs: using a tuple will produce a SystemConfigs containing the SystemConfig obtained by converting the first nested IntoSystemConfigs and the second nested IntoSystemConfigs etc etc
• IntoSystemSetConfigs: likewise

The difference between filters and Bundle/IntoSystemConfigs/IntoSystemSetConfigs is that the former also has a notion of logical or, while the other don't have it. Note though that WorldQuery does have a notion of "or" in the form of AnyOf

[iiYese]

I would argue that most do express an "and", although kinda implicit and not always logical

They express a structural "and" which is more comparable to intersections and unions in set theory than boolean logic. Tuples in filters like With<(..)> and Without<(..)> like in the mentioned pull request would express something more in line with this where they currently do not. Logical semantics would be introduced with And<(..)>.

I don't think pedantic details that exist only out of technicality like this without important consiquences are good justification for/against designs. The coupling of these 2 semantics as they are currently noticably makes filters much more difficult to design for than the other tuple APIs.

[iiYese]

Closing as no longer want this suggestion.