Add editor check for compatible visibility layers for CanvasItem

[AThousandShips]

The wording might need some improvement, and need confirmation that this catches the full behavior of this feature. It doesn't check the cull layers of any viewport, can add if desired but keeping it simple for just the hierarchy (and an error for the viewport might be annoying if you want them to be invisible at the start just by the layers, but the hierarchy itself would usually be an accident I'd say)

In short: This checks that the condition for visibility is met, i.e. that a CanvasItem has at least one layer shared with all parents until either the root or one parent that is top-level. To avoid annoying potential false positives it also doesn't check if the layers for the node itself is empty, that feels like something intentional and shouldn't throw a warning

Correctly updates when layers of parents update, as well as when top-level changes for parents and self

• Closes: Viewport cull mask and canvas item visibility layer not working #93316

See (I'd say regardless of that one being merged this one is useful, but not vice versa):

• Change default value for Visible Layer in canvas item #93335

[AThousandShips]

There, changed to using get_parent_item and moved the configuration update to _top_level_changed which is propagated to child nodes to future proof it with that part, and left a note in the layer setter

[AThousandShips]

I can move this back to set_as_top_level if there would be performance concerns calling it down a deep tree and add a note to this as well, works either way

[AThousandShips]

So if someone on the rendering team could confirm some details of the functioning here if there's something missing, to clarify:

• This seeks to catch cases where the hierarchy is obviously unworkable, where there's little to no reason to assume a setup is valid, where a node can't possibly be visible
• It doesn't care about the flags on the viewport, partially because this isn't easily accessible in the editor, and partially because that could be something the user wants to change to make nodes visible or not later

Here's the assumptions made that I'd like verified (based on the wording in the docs and other conversations as well as reading the code):

• Top level nodes are considered the root for these calculations
• The check stops with the top most canvas item, either having no canvas item parent, or being top level (based on the server parent assignment code elsewhere), and doesn't jump in the hierarchy or otherwise check for nodes higher

In other words, is there potentially something further needed than the direct traversal of canvas item parents here