[ax] Add --max-changes option to stop after N changes

[TomasVotruba]

Why

Agents and scripts running Rector unattended need a blast-radius rail: apply a bounded number of changes per run, review, then continue - instead of rewriting a whole codebase in one pass. There was no way to cap how much a single run does.

What

New --max-changes=N option. Once N changes (rule applications) have been made, the run stops and leaves the remaining files untouched.

rector process --dry-run --max-changes=50
# > stops once 50 changes are reached, rest skipped

• N counts changes (rule applications, i.e. RectorWithLineChange entries), not files - a single file can carry several.
• Enforced in the sequential file loop (ApplicationFileProcessor::processFiles): after each file, if the cumulative change count reached the limit, break.
• The limit is checked between files; the file that crosses the threshold is finished, so the applied total can slightly exceed N (a file is processed atomically). It never starts the next file.
• A global counter cannot be shared across parallel workers, so --max-changes forces a single-process run (same approach --debug uses).
• N must be a positive integer; 0 or non-numeric is rejected.

The changes made before the stop are kept (written on a real run, shown on --dry-run) - the point is a bounded chunk of work, not a rollback.

Tests

• testMaxChangesStopsAfterLimit in ApplicationFileProcessorTest: two files, 2 closures (= 2 changes) each; --max-changes=2 stops after the first file -> only 1 file diff, proving changes are counted, not files.
• composer check-cs, composer phpstan clean; verified on the CLI.