Qt: reimplement NavigableFocusScope as attached properties

This MR aims to refactor NavigableFocusScope in order to make it usable without the need to inherit from it, the main drawbacks where:

• The inheritance requirement was leading to many cases where we end up using KeyNavigation.xxx and Keys.xxx directly to handle navigation.

• Each methods potentially match a different key set.

• Interoperability might need some extra work, as we need to be sure to be able to fallback to NavigableFocusScope functionality when crossing domains.

• Code's harder to debug and to read due to heterogeneity.

this MR aims to not introduce new concepts, this implements the same behavior as NavigableFocusScope, then porting components to use it.

Further improvements:

• It should be possible to remove the need to specify the parentItem, we can just walk the QQuickItem tree and look for attached properties in the parent, in my tests this works in 90% of the cases, with a little care this should be easily doable.

• We can make Navigation inherit QQuickItemKeyFilter. with this, Navigation would be at the same level as KeyNavigable.xxx and Keys.xxx and we wouldn't have to manually redirect KeyPress to Navigation, the Keys.priotity:, Keys.onPressed: boilerplate.

  The main obstacle is that QQuickItemKeyFilter is defined in Qt private headers, we first need to decide if we want to use them, then the second issue is Qt pkg-config files doesn't provide the private include path. We would either need to guess them or retrieve them using qmake or something.

• expose KeyHelper to both C++ and QML, to avoid code duplication

• FocusReason and visual focus: I did pass the FocusReason when navigating, though I'm not sure how this can be used. As far as I understand this is stored in the window, but the window from the QML point of view might be a fuzzy concept, as we're doing all sorts of things with the compositors. I'm not sure how we can retrieve safely the focus reason.

  Either we can:

  • QtQuick.Control provides its own mechanism to handle the focus reason and the visual focus. We might enforce our component to inherit from control (this is already the case for most of them), but we probably don't want everything to be a Control. For instance NavigableRow will receive the focus and acts like a FocusScope it may need to know the focus reason to set the focus on the first or last element, but this isn't itself a control, we don't want it to be listed as a control when navigating through tab. The same probably goes for list/grid views.

  • Use @bunjee patch (MR !278 (closed)) which can probably easily be extended to store a focus reason. This is easy to implement but there might be some edge case we haven't foreseen.

  • use !278 (closed) for the visual focus and retrieve the focus reason from the window, I don't know if this can work.

• @fuzun did some work to improve key navigation in the player controller, I tried to do minimal changes in these places to not overstep too much on his patch. Though I think it would be best to first solve the FocusReason issue first.