Added hysteresis for popup sub-menus

[EricEzaM]

This adds a small lag effect when opening submenus which allow the user to move directly to an item on the submenu without worrying about avoiding the autohide regions.

I tested with Windows 10 submenu's and seems like their timer is just under 0.5 seconds, so that is what I used. The timer only starts when the user enters an autohide area for the first time. Again, this simulates the behaviour I observed on Windows 10. Please note this is a delay-only based implementation. I am not doing any fancy mouse-movement tracking or prediction - that's overkill imo.

Builds on #41640
Closes #11219
Supersedes/Closes #35487

CC @KoBeWi

Note how in the below GIF I actually enter autohide areas on my way to the submenu, but it does not close.

[KoBeWi]

If you are already doing it based on Windows, the options should get highlighted immediately after hover not after timeout. Otherwise they feel unresponsive.

Compare this

To this

Also, this is less important, but double-nested submenus don't work correctly:

(this is the attached project from my old PR)

This is similar to the problem with my old PR which I never fixed. It's probably fine if you don't fix this either (i.e. leave for another PR), as editor doesn't use double-nested popups anyways.

Other than that the implementation is fine. The timeout feels a bit too long, but this might be because I'm using debug build.

[EricEzaM]

@KoBeWi I have fixed the first part. It was a bit of a mess about because of how a submenu would grab focus when it was opened. Now by default it doesn't. It only grabs focus when mouse enters it, which means that the behaviour in your first GIF is fixed. Some adjustments were also made in popup.cpp which defines if the popup should close when the parent is focused. If this was not done then the submenu would just flicker forever as it was activated and then closed due to the mouse being in the parent.

As for the second issue... it is really confusing. Sometimes it happens, sometimes it doesn't. It seems very inconsistent and I cannot determine the cause of why it happens. During debugging it seems that the top level popupmenu gets hide() called on it after the first submenu is hidden where delete_sub_window(window_id) is called in Window::_clear_window. It thinks that for some reason the main window was focused, which hides the main popupmenu. But this only happens when you have a nested submenu at the second level. It does not occur at all if you only have one submenu... really confusing.

I also reduced the delay time to 0.3 seconds, to match the submenu popup timer.

Fix 1:

Issue 2, very inconsistent.

[KoBeWi]

The get_close_on_parent_focus() is probably unnecessary as it's never used. Also not sure if you should mix style changes into this PR (the p_over stuff), at least in one commit.

Other than that, this looks fine now.

[EricEzaM]

Updated. Yes, the get method isn't used but it needs to be there if bound to scripting languages.

[akien-mga]

Thanks!

[Maran23]

From my testing it looks like this introduced #70361.
Although even if this is reverted the behaviour still feels a bit sluggish, so I think this just made it more noticable.