Add queries that filter based on change detection

[joseph-gio]

Rebase of #30.
Resolves #23.

Adds support for trait queries that filter based on change detection.

TODO: describe the different kinds of query supported

[bzm3r]

Sorry, this took a while! I have the lay of the land again, and the tests are passing, so that's good.

I used this review to address some of the comments you left on my pre-rebase PR, so there are some code/comment suggestions I have provided. Mostly they are doc improvements.

The biggest issue I think is that we should be using TableRow instead of usize in all.rs, and merging the rebased PR as is will cause at least one incorrect regression there (see comments).

I also have a lot of nits with the original code I wrote...just so much unnecessary code duplication? Or maybe I am being overly sensitive to it, but I worry that as is, the code will be extremely hard/painful to maintain.

Depending on which code duplications you think are reasonable/valuable to eliminate, we could decide to:

1. merge as is, and make issues for their elimination, which I am happy to spend the rest of the week eliminating/addressing

2. I can submit PRs to the change-detection-rebase that address them, before we merge.

[bzm3r]

I noticed that in lib.rs we have "registry sealing" tracking whether a registry is sealed or open: https://github.com/JoJoJet/bevy-trait-query/blob/2071f9c948358f0959b538ecf54f3a54cc6de923/src/lib.rs#L286

If the seal check fails, a panic is issued: https://github.com/JoJoJet/bevy-trait-query/blob/main/src/lib.rs#L311

I am wondering: is it worth putting a similar, explicit panic-check here that enforces the conditions the debug_unreachables are based on?

[bzm3r]

The sysinfo crate is failing miri? https://github.com/JoJoJet/bevy-trait-query/actions/runs/5294385777/jobs/9583666769?pr=42#step:6:344

[joseph-gio]

I've removed much of the code duplication by turning the All filters into iterator adapters over the standard All form. This keeps mostly the same API while removing many lines of code. There's still a bit more deduplication that can be done (specifically in the actual WorldQuery impls), but I think this is an improvement. I still need to think of some approaches for improving the One adapters (maybe even by just removing them as mentioned previously).

I'd appreciate another look @bzm3r :). Also, I think that your idea of removing the added/changed WorldQuerys in favor of just adding methods to ReadTraits and WriteTraits is attractive in its simplicity, though I haven't tried it yet.

[joseph-gio]

I've slimmed down the API for the One filters, and renamed ChangedAll back to AllChanged, since I think it reads better. I originally asked @bzm3r to rename them, but I think I was being a bit too particular.

[joseph-gio]

I took @bzm3r's suggestion of removing the iterator filters in favor of simple iter_added() and iter_changed() methods, which remove a lot of bloat from this PR. I plan on merging this soon.