Node3D maintains its own list of Node3D-only children (separate from the Node), in order to (in theory) make child iteration faster for only node3d children. The same happens with CanvasItem and CanvasItem children.

The problem is that these lists are stored as a linked list, and there is no reason to require linked list. Linked lists are bad for cache.

Forward port of #107480

Benchmark

(See 3.x PR, but gains should be similar in 4.x)
before: 157 fps
after: 280 fps

The benchmark creates a large number of Node3D children to the root node, then rotates the root. This stresses the _propagate_transform_changed() which utilizes the children list.

Notes

• This is actually a no brainer, I also tested removing the Node3D children list entirely and utilizing the Node children list instead with fast casting, but this PR is still faster (because of no need for cast checks).
• Some NULL checks in the original were redundant, I don't think these pointers can be NULL given the code here.
• I may end up being able to use this list for SceneTreeFTI now it is faster, instead of Node children. Not 100% on this yet, but worth looking into.
• Have done the same for CanvasItem, the same applies.
• I've done testing on startup / shutdown times, and as expected there's no significant difference.

Additional

These lists are similar in 3.x and 4.x. Unlike the Node children list, they are unordered, so no need to change when rearranging children, only when entering / exiting tree, and removing items is O(1) rather than O(N).

Instead of relying on the ability of linked list to remove an element fast, we use remove_at_unordered to remove elements in O(1). With linear lists, and keeping an ID of which child we are in the parent list, we have to rejig the child that is moved during remove_at_unordered(), and reassign its child ID. That should be the only thing required to keep the IDs in sync.