As-needed change detection

[SpecificProtagonist]

Objective

Make change detection optional in a runtime-configurable way.
See #4882.
For prior art, also see #6659, which statically determined whether query items would be change-detection-enabled based on the type of the component.

Solution

Querying for &mut T now gives you a MutMarkChanges<T> instead of a Mut<T>. This still writes change ticks, but doesn't let you read them. Resources are unchanged.

By default, change detection is disabled for all components. It can be manually enabled via World::enable_change_detection::<T>(). Using a query with a Ref<T>, Mut<T>, Added<T> or Changed<T> term also enables change detection for T if not yet enabled, but prints a warning if entities with this component exist (as their change ticks were missed).

Updating change ticks via MutMarkChanges does not branch: When change detection for T is disabled, they're instead written to a dummy sink.

This PR doesn't turn change ticks into components of their own, which can happen in a followup if desired.

typed	mutation	tick reading	type	new query term	old query term	PR
❌	❌	❌	Ptr	—	—
❌	❌	✅		—	—
❌	✅	❌	MutMarkChangesUntyped	—	—	➕︎
❌	✅	✅	MutUntyped	—	—
✅	❌	❌	&T	&T	&T
✅	❌	✅	Ref<T>	Ref<T>	Ref<T>
✅	✅	❌	MutMarkChanges<T>	&mut T		➕︎
✅	✅	✅	Mut<T>	Mut<T>	&mut T, Mut<T>

Many methods that previously worked with Mut/MutUntyped now have both a version with and without read access to change ticks (this is responsible for much of the line count; if you review this PR, going commit by commit helps). There's likely some opportunity for deduplication there, but I wanted to go with the simple solution for the initial PR.

I'd also be happy to hear about better name suggestions – e.g. should Mut be renamed to something like MutWithTicks and MutMarkChanges to Mut (and which one would be easier for migration)?

Draft

• Performance
  • Benchmark this!
  • Does this allow autovectorization? Should the dummy sink be turned into an array of 4 or 8 or so change ticks to help with that?
  • Work on parallel iteration so multiple threads aren't fighting over ownership of the same cache line
• Is this the user interface we want – are there footguns (e.g. with SystemRegistry), bad edge cases, or unwieldiness?
• add change tick access for dynamic queries & ReflectComponent
• Adjust APIs that expect change tracking to always be present, write new tests, write documentation incl. migration guide

Testing

(todo)

Showcase

let id = world.register_component::<Foo>();
assert!(!world.components().get_info(id).unwrap().change_detection());

Migration Guide

(todo)

[alice-i-cecile]

I'd also be happy to hear about better name suggestions – e.g. should Mut be renamed to something like MutWithTicks and MutMarkChanges to Mut (and which one would be easier for migration)?

I would prefer this flavor of design: the "nice" name should be the one returned by default.