Add FilteredAccess::empty and simplify the implementatin of update_component_access for AnyOf/Or

[SkiFire13]

Objective

• The implementation of update_component_access for AnyOf/Or is kinda weird due to special casing the first filter, let's simplify it;
• Fundamentally we want to fold/reduce the various filters using an OR operation, however in order to do a proper fold we need a neutral element for the initial accumulator, which for OR is FALSE. However we didn't have a way to create a FilteredAccess value corresponding to FALSE and thus the only option was reducing, which special cases the first element as being the initial accumulator.

This is an alternative to #14026

Solution

• Introduce FilteredAccess::empty as a way to create a FilteredAccess corresponding to the logical proposition FALSE;
• Use it as the initial accumulator for the above operations, allowing to handle all the elements to fold in the same way.

---

Migration Guide

• The behaviour of AnyOf<()> and Or<()> has been changed to match no archetypes rather than all archetypes to naturally match the corresponding logical operation. Consider replacing them with () instead.

[chescock]

This makes those implementations much clearer!

[Guvante]

Does this change the behavior of Or<()>? The old code seems to be a no-op while the new code seems to remove all filter_sets. Mostly from a breaking changes standpoint.

[SkiFire13]

Does this change the behavior of Or<()>? The old code seems to be a no-op while the new code seems to remove all filter_sets. Mostly from a breaking changes standpoint.

Yes, this is already mentioned in the migration guide.

I could avoid this breaking change by adding a bit of complexity in the code, but the current behaviour seems wrong to me so this is also an occasion to fix it. Or should match those archetypes that satisfy one of its inner filters, but if there's no filter then no filter is satisfied and no archetype should be matched, while the current behaviour is to match all of them. That said, I don't think someone is actually using Or<()> since it makes no sense, but if they are then chances are they expect the new behaviour, not the old one.