Native MenuBars and Menus in Qt Quick

This task will summarise the investigations done to support native menu bars and menus in Quick. Unless specified explicitly, this will exclude macOS, where native menu bars and menus works fine, both for Widgets and Quick, and will therefore be used.

During the work to implement native menu bars in Quick, it was discovered that Widgets is not using native context menus and menu bars. Instead, for the menus, it creates top-level popup windows, and draw the menu contents using QPainter/QStyle. This means that large chunks of menu code in QPA for Windows and xcb/gtk3 are currently not being used (1). Why this code is not used is not clear, and any information that can shed more light the that decision is welcome. But from our own investigation, we found out that:

1. The QPA MenuBar for Windows doesn't handle well if you change the menu bar at run-time, such as adding, removing, or changing menus. Any such changes won't take effect until you move the Window to a new place on the screen. And while moving the Window, the menu bar will flicker. At least inside a Virtual Machine (not tested on a real device).
2. The QPA MenuBar for Windows doesn't look very native. It's written with MFC, and has an old look. "Modern" Windows application, such as MS Paint, typically combines the MenuBar into the ToolBar / Ribbon, and use larger fonts and more space. And the drop-down menus roll down instead of fading in.
3. The menu bar implementation in Gtk3 doesn't seem to work at all. No menu bar will show if you use the MenuBar from Qt.labs.platform.
4. Menus used as stand-alone context menus seems to works fine, both on Windows and xcb/gtk. But it's important to know that while they're open, they both run in a blocking native event loop. This means that we don't receive MouseEvents in Qt. But for normal stand-alone context menus, this limitation doesn't seem to cause any issues.

All-in-all, it seems that in order to use QPA for native menu bars, a substantial overhaul, or even rewrite in case of Windows, is needed. We therefore choose to use non-native menu bars in Quick for the first version (except, as mentioned, on macOS). It important here to underline that using a non-native menu bar doesn't necessarily mean using in-scene drop-down menus. The next natural step was to investigate if we could then use native context menus together with non-native menu bars. But this was found to be problematic. The reason is that a non-native menu bar needs to receive hover events while a drop-down menu is open. Otherwise the user cannot pan the menu bar and expect the menus to open and close as he hovers the menu titles. In Widgets, for example, a QMenuBar has an event filter (or sort of) on QMenu to achieve this. But since a native context menu run in a native event loop, a non-native menu bar will not receive any mouse events. So this will not work. Which is perhaps also a contributing reason as to why Widgets have abandoned using native drop-down menus? So it's basically an all-or-nothing approach; Either both the menu bar and the menus are native, or none of them.

As a result, the solution we'll use for now, until the issues above have been resolved, is to use non-native MenuBars in combination with real top-level popup windows (if available), equal to have Widgets does it. For OS' that don't support multiple windows, we'll fall back to use in-scene menus. But different from Widgets, we'll still plan to use native menus for stand-alone context menus, since we haven't found a reasons not to, yet. 

1. Except by the Qt.labs.platform Menu and MenuBar