Systems that can run multiple times that internally reset change detection

## What problem does this solve or what need does it fill?

Sometimes you need to do work based on calculated components before they would normally be calculated.

You could move the corresponding systems before your system but systems after that system might update these components again.

You could run the corresponding systems before your system by adding them again right before your own but this will cause them to be calculated twice.

## What solution would you like?

It would be nice to have some way to configure a system to have an internally change detection that is synced across multiple instances of itself. Basically resetting each time it runs even if it appears multiple times in a schedule.

I don't think this should be the default behavior for systems because it is just an optimization for some use cases.

Basically having a method on system that could recreate a new system that has this behavior.

Something like `update_system.internal_change_detection()` which returns a system that can be used multiple times.

Could also be a different query filter like `InternalChanged` or `InternalAdded`.

I don't think "internal" is the best word for this but it is the only thing I can think of right now.

## What alternative(s) have you considered?

- living with repeated work
- living with one frame delays
- implementing an external library

## Additional context

My use cases in the past have been with `GlobalTransform` so an external library would not be an optimal solution.

I just lived with a one frame delay because I didn't think of finding the systems responsible for updating `GlobalTransform` in Bevy and reading them before my system. This would cause them to be calculated twice even if they weren't changed between the two duplicate instances of the systems.

No files, tests, or entry points are named. Start by tracing Bevy's system scheduling and change-detection behavior, especially the systems that update GlobalTransform. Before implementation, agree on whether this should be a system API or query filter and define how repeated scheduled instances should reset detection; the issue is done when that design is implemented with coverage for repeated runs.

Written by the indexing model from the issue text.