Introduce change tracking helper

[Ralith]

Much like CommandBuffer and serialization support, I think this is non-obvious, useful, and self-contained enough to merit inclusion even though it's implemented purely in terms of the public API. I'm interested in feedback on whether this would indeed be useful to people, and on the API design, including the detailed semantics.

[kanerogers]

My 2 cents

What I like:

• It's opt-in
• Self-contained
• Documentation on track is excellent
• Conceptually simple

What I don't like:

• Some module-level documentation would help with visibility (happy to volunteer for this)

[Ralith]

module-level documentation

The module isn't public; I'm just reexporting ChangeTracker and Changes at the top level. I'd welcome a succinct doctest for ChangeTracker to illustrate its use, though.

[h3r2tic]

Looks quite handy, and I like how small and clear an implementation this is! FWIW our project enjoys change tracking in Bevy via DerefMut marking components dirty (as opposed to running PartialEq). It most cases it wouldn't matter much, but at least in one one case the component involved is a chonky one, and I suspect that with this implementation, we'd need to layer an additional dirtiness tracking thing on top in order to avoid the cost of PartialEq.

I suspect there could be a simple workaround; we stash a whole CPU-side collision mesh into a component, and use change detection to trigger its upload to the physics engine. We could probably keep a change counter or a content hash in a separate component, and make the PartialEq run quickly anyway. For hecs you could probably just say in a doc "yo don't do change detection on fat structs or else", and recommend a silly workaround like this.