There were a few miscellaneous changes that didn't fit thematically into the other optimization PRs, so I've grouped them here.

editor_node.cpp transform flushing

The editor_node.cpp change is necessary because some editor plugins expect the transforms to be properly set up during the _load_editor_plugin_states_from_config call later.

As a concrete example of an issue, open the Mesh3DInstance25k.tscn file. Opening it takes ages because of a convoluted path that triggers an issue in the DynamicBVH code. Because the instances all have the same local coordinates, they're initially loaded with identical transforms. They're added to the occlusion culler's dirty instance list, and then during the plugin setup something is freed from the culler, causing the dirty list to get processed. However, the transforms have never been propagated between scene loading and now, so everything is inserted at the same location. This triggers an O(n^2) edge case in the BVH.

I wouldn't have noticed this issue without it triggering a separate bug. However, both the official plugins and one user plugin end up doing twice as much setup work as they should, because they process the state of the world during the plugin, and then get all the transform updates later. Setting up the transforms properly first seems like the correct thing to be doing, anyways.

Here's an example of a user plugin running into this issue.

I'm not sure this is exactly the right place to put the flush_transform_notifications call, it could also be put inside set_edited_scene, but I erred on the side of the least impactful change.

canvas_item_editor_plugin EDITOR_GET removal

When I profiled the delay when selecting canvas items in the editor, literally 60% of the time was spent on this single EDITOR_GET call, so I cached it. The delay in question is small, but enough that it felt laggy to me, so I looked into where the time was being spent and found this.

_node_visibility_changed cache use

Perhaps there's a good reason not to do this, but I couldn't find any issues when testing it. It does dramatically improve the time to update the visibility of large numbers of objects at once.

1. Open Sprite2D25k.tscn
2. Select 25000 sprites
3. Toggle the visibility

On master, step 3 alone takes ~50 seconds. With this PR, it takes about a half a second.

If you want to test this particular speedup yourself, it'll likely be difficult without also applying #109515 so that large selections are less problematic.

All performance tests were run on builds made with the following command: scons optimize=speed_trace debug_symbols=yes platform=linuxbsd dev_build=no production=yes.

The test project editor-optimization-test-scenes.zip consists of a series of scenes that each have 25,000 of a common type of node.