[3.x] Fix 2D MultiMesh hierarchical culling

[lawnjelly]

Fixes updating local bounds for MultiMeshes used in canvas items by introducing a back link.

This version as well as fixing CPUParticles2D, also fixes MultiMeshInstance2D and direct use of VisualServer.

Fixes #80086
Alternative to #80090

before

culling_broken.mp4

after

culling_fixed.mp4

This PR is basically an automated version of #80090 . canvas_item_invalidate_local_bound() is called automatically when changing the MultiMesh. This means users don't have to call this function.

The downside is that the machinery for maintaining the backlink is fairly complex, and complexity often equals bug prone and more maintenance burden. The system is equivalent to that used for Skeleton, which maintains a backlink to the canvas_item. However, the situation here is more complex for two reasons:

1. MultiMesh references are stored in Item commands, rather than directly in the canvas_item. This means that adding / removing links has to to take place via the command list, rather than directly via the canvas_item. There can also potentially be multiple commands referencing the same MultiMesh. There is no need to reference count here, because commands are only cleared all at once, so there either is, or is not a reference held at any one time.
2. Order of deletion is not guaranteed. We have to support both the MultiMesh being deleted before the canvas_item, and the other way around, with code to support both.

Designed to keep CanvasItem "light"

• We could alternatively keep a LocalVector of linked MultiMeshes on the CanvasItem, which would in some ways be simpler (with no need to iterate through commands). However we want to keep CanvasItem as light as possible (most CanvasItems will be rects, and not care about MultiMesh), and storing the links in the commands is effectively "free", so it's probably worth the extra hassle.
• Storing the canvas_item RID on each Command::MultiMesh is a little superfluous, but it enables us to clear out the links in the destructor with no cost to CanvasItems that do not contain multimeshes. The 8 extra bytes is likely to be unimportant, because most Command::MultiMeshes will only be stored singly on CanvasItems. Essentially it is more important to keep the typical CanvasItem light than the Command::MultiMesh.
  There may be a slightly better way of doing this (e.g. using a static or global to store the canvas_item RID during deletion) but storing the canvas_item RID is at least thread safe.

Notes

• It turned out for [3.x] Fix CPUParticles2D hierarchical culling #80090 that in order to support MultiMeshInstance2D we would have to introduce similar complexity scene side, so I'm now leading with this PR.

[kleonc]

Changes make sense, code looks good AFAICT.

I'd say don't merge without @clayjohn's review though.

[akien-mga]

Thanks!

[akien-mga]

I'd say don't merge without @clayjohn's review though.

Woops, I missed that one before merging. I'll ask Clay to review post-merge when he has time.

[clayjohn]

It looks fine from a visual review!