Consider valid candidates with overlap

[Murreey]

Description

• Reverting the logic of valid candidates again slightly, to consider how much a candidate overlaps the current focus, and allow for a small amount of overlap in each direction.
• Added an attribute to allow customising that threshold.
• Removed the corner checking logic in favour of this approach, as the corner checking didn't handle all the scenarios in the way we'd expect, and lack of customisation made it too stubborn.
  • Primarily it considered stuff 'to the right' even if it stuck out by a single pixel. Technically correct, but visually weird and unintuitive.

Motivation and Context

Here, going right from 1 would originally not go anywhere, as the target edge of 2 & 3 (their left edge) is left of the exit edge (right edge of 1).

However sometimes we want to be able to consider items that are 'right-ish' from the current focus, even if they are also offset in a different direction. So even though 3 is below 1 and therefore a valid 'down' candidate, it is offset enough to be the right that it should be a 'right' candidate too.

With this change, the target edge is effectively moved by a small amount, allowing for the actual edge of the candidate to overlap the current focus. Here the new lines represent the adjusted edges of each container. 3's adjusted edge is now to the right of 1's right edge, so it's considered a valid 'right' candidate from 1.

By default, the edge is moved by 30% of the element's width/height - effectively allowing for up to 30% of the candidate to overlap with the current focus.

The data-lrud-overlap-threshold attribute allows for tweaking that threshold on a per-element basis. It takes a float from 0.0 to 1.0, representing the percentage of the element that can overlap and still be a valid candidate. The default overlap is 0.3, 30%.

Here item 3's allowed overlap is 0.1 (10% of its width), so it is no longer valid. A value of 0 would return to the original behaviour and only consider candidates that don't overlap at all as valid.

How Has This Been Tested?

New integration tests.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.