Automatically calculate swipe zones

[iliazeus]

Using the information of what swipes are available for a key, we can calculate swipe zones without relying on explicit SwipeNWay.

The algorithm assigns each SwipeDirection a "precise direction" vector - for example (+1, -1) for TOP_RIGHT. It then uses a dot product to calculate a cosine of an angle between the swipe and this precise direction. The biggest cosine (that is, the smallest angle) that has an action attached wins, but only if the cosine is positive (that is, if the angle is in the ±90 degree range).

This new behavior differs from the old one in a few notable ways, though:

1. It is no longer possible to reduce the swipe zone size by utilizing SwipeNWay.EIGHT_WAY, but then only setting the four cardinal directions. This behavior was fairly obscure, and AFAIK no layout was using it intentionally.

2. Some swipe zones are now bigger than before. Notably, if TOP, BOTTOM, and LEFT all have actions attached to them, then swiping right would trigger the closest of the TOP and BOTTOM actions - which wasn't happening with SwipeNWay.FOUR_WAY_CROSS. On the other hand, the TWO_WAY_* values do have this behaviour - swiping right on a TWO_WAY_VERTICAL would trigger one of the actions.

I'm still not sure if I like point 2 so far. It also looks like it would break the "ghost keys" feature. Point 1, I am okay with.

The end goal of this PR is to eliminate the need to set swipeType in keyboard definitions, in all or most cases. A more conservative approach to that would be to just calculate KeyItemC.swipeType in the constructor based on which swipes are set. I might just end up doing that instead, in a separate PR.

[iliazeus]

I also want to investigate dynamically adjusting swipe zone sizes based on the last few characters typed in a short tinespan, as a simple form of typo prevention. That is, making swipe zones of "likely" keys bigger, and "unlikely" keys small; and adjusting the "swipe or tap" threshold based on the "likelihood" of the center key.

[dessalines]

If the ghost key setting is on, you could also just assume 8-way, and override this automatic calculation.