Keep the class body in its existing order when merging

[SanderMuller]

The preparatory PR from #163. No 8.6 here, this only makes the order stable.

Why members move

compareStatements() rebuilds a class body by category:

$newStmtsToSet = $untouchedStmts;   // everything outside the current version window
foreach ($newMethods as $stmt) { ... }
foreach ($newConstants as $stmt) { ... }

filterStatementsByVersion() returns [$oldStmts, $newStmts] and the caller reads it as
[$untouchedStmts, $oldStmts]. So anything that has aged out of the window is written before every method,
wherever it used to sit.

Your DateTime example is exactly this. __wakeup carries #[\Until('8.5')], so its untilId is 80499.
Coming from 8.4 that is not below 80400 and it stays put. Coming from 8.5 it is below 80500, it becomes
untouched, and it jumps to the top of the class.

That also means the churn grows at each step, because more members age out every version.

The change

Walk the old body in its own order. Each member is replaced by its merged version in place, and whatever
the new version adds is appended after. Aged-out members keep their position instead of being hoisted.

Effect

Measured on the 8.5 to 8.6 run, which is what #163 does:

	files touched	pure reordering	additions only	net deletions
today	98	16	75	7
with this	82	0	75	7

The 16 reordering files are simply gone, and the other two columns are unchanged, so nothing else moved.
DateTime.php, DateInterval.php and DatePeriod.php are no longer touched at all.

The committed stubs were generated by the old order, so the first run after this reorders them once. That
is the one-time cost, and it is why this goes first.

No stubs are committed here, the workflow commits those on main.

[ondrejmirtes]

Thank you.