Continuing from the work seen in #6952, this PR establishes the unit-testing toolchain (karma, mocha, chai, etc) needed for gesture-recognizer unit tests to ensure robustness down the road.

After looking at the possible approaches we can take for unit testing the module, to ensure good code coverage, I believe we'll need two separate layers for unit tests.

1. DOM events -> input coordinate sequences
   • Ensuring that a properly-configured gesture receiver interprets events exactly as we expect and can reproduce previously-recorded sequences.
   • Timestamp emulation isn't perfect, though it's possible to approximate.
2. Input coordinate sequences -> gestures
   • By starting from input coordinate sequences, we can bypass the DOM entirely and use headless mode here.
   • We'll take valid timestamps on recorded sequences for granted here.

Timestamp emulation is possible due to a feature in https://github.com/sinonjs/fake-timers we haven't been using before (as found within SinonJS). I did decide to update our dev-dependency version for the containing package, as it was missing a rather helpful method for implementing the desired unit tests - runAllAsync wasn't supported in the old version.

At this point, we can only address point 1 above; there is no gesture segmentation or synthesis code written yet.

One big question worth asking:

• Would we be fine running unit tests without BrowserStack?
  • This should be possible if we run against just Firefox and Chrome, as both are generally supported on all major platforms.
  • May require a bit of build-agent setup (if the agents lack either browser at present).

Unlike with Keyman Engine for Web, we don't need to worry much about browser-specific keymappings here, let alone use of touch-alias elements, rotation, or the like. I could see worry about the shifting layout of the keyboard that results from rotation, but fortunately, the design addresses that almost inherently... and there's little issue with writing a unit test or two to ensure that shifts in important layout / configuration elements don't cause issues.

For now, I've provided a BrowserStack-based configuration (for CI) for the browser-based unit tests, but in my opinion, we should be safe to forego use of their service for this module if we could guarantee consistently-available browser(s) for use on all our build agents. ... which is probably why we're using BrowserStack, true. I don't think we need as extensive browser-coverage here, at the least.

@keymanapp-test-bot skip

All the previously-defined user tests are now unit tests!