Avoid crashes when engine leaks canvas items and friends

[YuriSizov]

Closes #85495. Code is gently stolen from the Vulkan renderer, which does a similar thing.

Now you'll see this with the MRP on exit:

servers\rendering\renderer_canvas_cull.cpp:2172 - 28 RIDs of type "CanvasItem" were leaked.
WARNING: 28 RIDs of type "CanvasItem" were leaked.
     at: RendererCanvasCull::_free_rids (servers\rendering\renderer_canvas_cull.cpp:2172)

Plus a lot of other leaks.

---

What happens, basically, is that when there is a leak we are left with some data in the RendererCanvasCull class. When we try to delete it, it attempts to delete all its memory, including RendererCanvasRender::Items it has in store. These contain commands which contain polygons. When you delete polygons, we need to access the RendererCanvasRender singleton. But this singleton is already null at this point (it is removed when the rendering server is finalized, whereas RendererCanvasCull is only removed when the rendering server is deleted).

So we need to do these things earlier and with more grace, and report to the user that they have a leak.

[YuriSizov]

I also noticed some outdated code that was out of place in relevant files, so I did a little cleanup. Seems like it dates back to 2787ad6#diff-2eaa5fdddb0bc4674976c8bbaeb5aab4c69d5a3c74fb1ead3a00f9e9c06a4f26, but after some additional changes the singleton definition should be moved to the class' own file.

Thanks @clayjohn for looking into it 🙃

[akien-mga]

Looks good to me overall.
Waiting for rendering team review to merge.

[BastiaanOlij]

This looks good to me, it makes perfect sense to add this check. It's helped us lots of times on the 3D side.

[BastiaanOlij]

We don't do this consistantly on the 3D side but if you search you'll see a few places I added it, but seeing that it can be very difficult to find the cause of the leak simply by a count, I check if a description was recorded for the RID (this is a debug/tools build only feature), than we print the description of the resource being leaked.

This also means off course that we need to get more consistent in recording descriptions when the resource is allocated. Something we can improve on over time.

[akien-mga]

Thanks!

[YuriSizov]

Cherry-picked for 4.2.2.