core: Implement keyboard navigation

[kjarosh]

Related to #5443.

This PR implements keyboard navigation for highlighted interactive elements.

When ordering objects for navigation, they are divided into two main categories:

1. objects directly behind the origin (taking into account the direction),
2. other objects.

Objects from category 1 always take precedence over objects from category 2.

Objects from category 1 are ordered according to their horizontal/vertical distance to the origin, and when two objects have the same distance, the default ordering based on the hierarchy is used.

Objects from category 2 are ordered according to their 2D distance to the origin. The distance is calculated between the closest corners of highlight bounds, and when two objects have the same distance, the default ordering based on the hierarchy is used.

In case of navigating down, there's an additional category (between 1 and 2) which contains objects directly to the right/left of the origin. In that category, objects are ordered according to their x-axis distance towards origin.

Note: the following implementation is still a little off. Its general idea is sound, but there are situations where the exact ordering in category 2 is inaccurate. It seems that FP's behavior in that case depends on things other than highlight bounds, (e.g. past iteration order), however this inaccuracy is not very important as keyboard navigation is performed by the user, and they may always navigate in some other way.

The following image visualizes the object selection preference when navigating down.

This behavior has been derived experimentally. In particular for category 2, points where navigation preference between two objects changed (first object constant, second with variable x and y) were always lying on a circle.

[Dinnerbone]

Thank you!