[3.x] Consistent render ordering for CanvasLayers

[lawnjelly]

Maintains scene tree ordering for CanvasLayers that share identical layer ID.

Fixes #25384

Notes

• This is a far more correct fix for CanvasLayers than previously attempted.
• It adds the overhead of maintaining a tree layer order, which in most circumstances should not be a problem, but is suspectible to the "notification explosion problem", so should ideally be used in conjunction with [3.x] Add deferred notifications #65581 and [3.x] Faster queue free #62444 .
• Given we are traversing the scene tree to establish render order, we could also consider the possibility of storing a render order for all nodes (if this would be useful for other purposes, killing two birds with one stone). This would involved some more effort to maintain though, as all nodes changes would require reordering (or maybe it could be done in the VisualServer directly during rendering).
• Same may be applicable to master if it has the same problem.

[clayjohn]

Changes look fine to me. I don't love having to traverse the whole scene when a CanvasLayer moves, but I think we are stuck doing it here so we can limit the check to when a CanvasLayer enters/moves/leaves the scene

[lawnjelly]

Just pushed a small bugfix, I noticed a couple of things:

• I was only calling set_layer() on the moved canvas_layer. This didn't sound correct, as the ordering of the other canvas_layers could also be shifted as a result, so now I'm calling set_layer() on each layer.
• The DEV_ENABLED warning was incorrect and likely to trigger, so I removed it.
  This was because historically I had previously been incrementing _layer_order_in_tree for each Node, but that is no longer the case, it is now only incremented for canvas_layers (to make debugging in VisualServer easier).

I don't love having to traverse the whole scene when a CanvasLayer moves, but I think we are stuck doing it here so we can limit the check to when a CanvasLayer enters/moves/leaves the scene

Yes it's a bit of a pain but it is the simplest implementation, and without evidence of this causing a problem it probably isn't worth optimizing at this stage (which would complicate the code and could lead to bugs).

Merging note

I would advise not cherry picking to 3.5 until we have tested in at least a 3.6 beta, due to the potential for the scene tree traversal to cause performance issue in unforeseen situation.

[akien-mga]

Thanks!