[Merged by Bors] - merge matches_archetype and matches_table

[BoxyUwU]

Objective

the code in these fns are always identical so stop having two functions

Solution

make them the same function

---

Changelog

change matches_archetype and matches_table to fn matches_component_set(&self, &SparseArray<ComponentId, usize>) -> bool then do extremely boring updating of all FetchState impls

Migration Guide

• move logic of matches_archetype and matches_table into matches_component_set in any manual FetchState impls

[alice-i-cecile]

PR description could provide a bit more context on what exactly these types are, but I'm happy with the changes themselves.

[alice-i-cecile]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• miri
• run-examples

[cart]

@BoxyUwU @alice-i-cecile

Came across this change while reviewing #4626: im not sold on this for a number of reasons:

1. This forces each caller of matches_component_set to decide what it means for an archetype or table to match a component id (edit: and a Query generally). This should not be externalized, it is a core part of what it means for a query to match an archetype / table.
2. It assumes that archetype matching will always hinge on ComponentIds. I think there is a reasonable chance that we will add things like "value based" archetype identity (ex: for things like indexing), which would split out our definitions of "matches table" vs "matches archetype".
3. We've removed a "duplicate" method from each impl, but it comes at the cost of additional implementation complexity because it adds the abstraction of "calling an arbitrary input function". It is much harder to tell whats going on (and the purpose of the function).

[alice-i-cecile]

1. I think this is an important consideration: I agree with your concerns here.
2. I agree that we'll likely have some form of value based matching. I'm reluctant to call this an "archetype", because of how much that further muddies the waters around what an archetype is. By itself I don't think this is a good reason to block this change; those changes are a long way in the future.
3. That's a fair criticism.

[alice-i-cecile]

@BoxyUwU, you mentioned you had rebuttals to these concerns but never remembered to actually write them down :)