Continues from #6878.

This PR introduces object-orientation designed to facilitate the tracking and handling of multiple active touchpoints and their related input(s). On touchstart or mousedown, a new TrackedPoint is initialized that will receive data for all further events during the lifetime of that touchpoint (or touchpoint-emulating mouse interaction) until it is considered ended or canceled.

The structure, as currently implemented, also records all incoming coordinate-timestamp pairs over the touchpoint's lifetime. This will greatly facilitate the ability to create unit tests for the module. In practical use, the plan is for these pairs to be progressively cleared once their role in a gesture's lifetime has been fully determined - unless an option is set to preserve them for "recording" mode.

This branch aims to establish a specific object-oriented design for each 'input' received by this module. That statement needs some unpacking, so here goes:

TrackedInput

This will be the top-level object for any single ongoing input event as determined by the gesture-recognition engine, even once completed. Note: as determined by the gesture-recognition engine. The goal is that this will model the expected user-experience of what "a single input" is, rather than the programmer interpretation.

For now, this class mostly acts as a wrapper for a single touchpoint. If/when we start supporting multi-touchpoint gestures - say, a two-finger swipe-like gesture (perhaps to fine-tune the caret's position in KMW) - both touchpoints should be considered as equal components of "the same" input.

As a result of this, the object offers an array of touchpoints, though the common case will feature only one. It is also intended for the input's corresponding gesture (or potential gesture states?), once determined, to be accessible here as a property.

TrackedPoint

This is the top-level object for any metadata particular to a single active (or once-active) touchpoint (or cursor-based emulation thereof). At present, its main role as a distinct class from TrackedPath is how it serves to match incoming events against the touchpoint, but there will likely be useful properties added later for ease of use by consuming objects that make less sense on a path property.

TrackedPath

This class will be responsible for tracking and analyzing the path of the touchpoint over its lifetime. While currently only supporting an array of coordinates, the current plan is for path segmentation to occur either within this class or from the view of this class, without the need for any of its parents or their properties. There will be a not-insignificant amount of code for this goal, so it's best to keep it isolated away from pretty much everything else if we can help it - that's part of the reason for keeping it separate from TrackedPoint.

There's also some nice interface-semantics design reasoning behind this:

touchpoint.path.on('step', ...); // Event generated whenever the touchpoint has a new event, taking another "step"
touchpoint.path.on('segmentation', ...); // To be generated whenever the path identifies a segmentation boundary

// Accessing path data
touchpoint.path.coords(); 
touchpoint.path.segments();

// Which is easily distinct from (a potential)...
touchpoint.coord(); // the _current_ coordinate of the touchpoint.  (Not yet implemented)
// because of the collective structure of the related objects.

The 'path' may be 'terminated' with instructions to invalidate the related touchpoint (e.g, due to roaming beyond supported bounds) or to indicate that the touchpoint has been lifted, ending its lifecycle. (The core event processing 'engines' operate from this view, after all.) It also supports related events. Both of these aspects are separate from, but connected to, similar instructions and events on TrackedInput.

@keymanapp-test-bot skip

The following two PRs will set up better-tailored test resources.

Note that going commit-by-commit may be a little tricky here if that's your review style; a major rework occurred after a certain point. For that, I made the rework in a branch based on #6970 and then backported all relevant changes to their best-matching PRs, so there's likely to be quite a bit of 'splicing', and thus instability in the midst of those commits.