Simplify the overlay and highlight system

[Nathan Lovato]

The overlay system targets many parts of the editor individually, making input management tricky at times. This was initially done, among other things, to allow resizing docks, by leaving an unblocked space over them.

But now we feel it's not something we want to let users do constantly: the more standard and controlled the interface is, the more reliable we can make the tour experience. Tour developers can still allow users to interact with resize handles by creating highlights that are large enough.

The task: Rewrite the overlay system to use a single overlay for the entire editor. That way, the overlay is always easily accessible, we can use a single overlay and dimmer per window, and all highlights are linked to that window's overlay. This will fix edge cases like nested overlays fighting with each other.

To do:

• One overlay and dimmer gets created per window at most.
• Ensure that user mouse input is polled per window, and that mouse input doesn't leak past the current window the mouse cursor hovers.
• Highlights or part of them still get added as children of individual control nodes to match their size and visibility (so a highlight in a specific dock doesn't show before changing main screen during a step, for example).
• All highlights in a window are referenced/linked to this window's overlay. Including highlights of tabs, tree items, item list items, etc.
• Unless we need to keep them for some reason, remove the controls_map dictionary and overlays / highlights maps in EditorInterfaceAccess and Overlays classes.