Flush delete queue after process frame timers

[KoBeWi]

After timers are processed in process frame, the delete queue is not flushed, which makes queued nodes exist until next frame, leading to unwanted behaviors. This is unlike physics frame, where the queue does flush after timers.

This is surprisingly easy to run into, because SceneTreeTimer defaults to process frame. Consider this code:

await get_tree().create_timer(0.1).timeout
queue_free()

The node will be freed one frame after it was queued, instead of the same frame as usually happens.

I made a reproduction project for a case where this is relevant:
NodeStayer.zip
Run bug.tscn and nobug.tscn and compare the results.

[lawnjelly]

This makes sense to me although could do with more eyes to check.

A look at the blame history for this file suggests the relative order may be rather haphazard, with things inserted without having the reasoning available for the current order (this is where comments could have really helped, with comments indicating the reason for the current ordering).

e.g. In #63026 I have no idea why the timers were placed after flushing the delete queue, as timers might decide to delete something... Ah the existing timer code was there already, but the reasoning is lost to time / github history 😁 .

For instance if shifting the flush delete queue to the end, maybe add a comment that "this should happen last because any processing that deletes something beforehand might expect the object to be removed in this frame", otherwise other contributors will do the same and add things after it because they are not sure where to add. You could possibly flush the delete queue after the transform notifications, but in theory it might be better before because something might be deleted that doesn't require a transform notification.

[KoBeWi]

Added comments and moved the delete flush after transform notifications. It's more consistent this way.

EDIT:
Seems like the push has problems again 🙄

[akien-mga]

A bit late in the 4.3 cycle for that, should we give this a go early on in the 4.4 one?

Adding an approval to keep track of it, if anyone disagrees with the change, please voice it :)

[KoBeWi]

Replaced by #93871, because GitHub decided to ignore pushed changes.