Column change detection for immutable components

[notmd]

Objective

• Implement column structure change detection for immutable component. This will allow to filter at table/archetype level for Query<(), Changed<SomeImmutableComponent>>

Solution

• Adopt change from column/table level change detection #11120 but for column of immutable component only. This change doesn't need to store an atomic because immutable components can only be changed by inserting so performance overhead is minimal.
• Add change_tick field to Column/ThinColumn. Change tick will be updated when inserting, replacing or removing elements. Updating when removing seems unnecessary because change detection doesn't detect removal. I am still updating it because I want to use this somehow to help implement query.is_changed(). We may consider introducing a separate tick for removal in the future.. Change tick will be update when inserting or replacing elements.

Testing

• I have added a few new tests to test the archetype_filter_fetch
• I also update the change detection benchmark for immutable component
• Here the benchmark result for Query<Entity, Changed<T>>. You can reproduce this by running cargo bench -p benches --bench ecs -- --save-baseline current none_changed_detection and critcmp benches current -g '^(none_changed_detection/\d+\w+::\w+::[A-Z][a-z]+)'
  
• Unfortunately, I can't benchmark the overall ecs overhead on my laptop, too much noise. But I believe the overhead is very small. Really appreciate someone with good computer can verify my words.

---

Future work

• Stop allocating changed_ticks for immutable component. Because it can't be mutated, use added_ticks for is enough.
• Expand this to mutable components without hurting performance.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-18788

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[notmd]

I have no idea what miri is complaining. Help is appreciated.

[notmd]

Benchmark for update_ui_context_system, yellow is main, red is current branch in many_buttons. This is the only system I can find in Bevy that benefit from the changes. Maybe we can push for more immutable components in futures
cargo run --example many_buttons --release --features bevy/trace_tracy