bug(web): Firefox hanging on interrupted keyman.addKeyboardsForLanguage during page init

**Describe the bug**
Okay, _this_ one's pretty odd and does seem to be browser-specific. Discovered when pseudo-testing #6791.

When loading one of KeymanWeb's `testing/` pages that uses `testing/commonHeader.js` _in Firefox_, if the "return to testing home page" link is taken before the _**Dzongkha**_ keyboard request is fully processed, the corresponding browser tab will deadlock.

I have confirmed the last detail mentioned above by commenting-out this line:

https://github.com/keymanapp/keyman/blob/ead21aabba50bd63774a4af534d2e3d537f87886/web/testing/commonHeader.js#L112

When just this one line is removed from the header, the reproduction below _immediately_ stops working. Also note that this is the single 'keyboard' added via language name at page init. I cannot seem to reproduce the error by calling the function through user-interaction after init and quickly clicking the link.

**To Reproduce**

1. Go to the "Test unminified Keymanweb" testing page while using Firefox.
- For ease of testing, I recommend duplicating the tab, then creating a new window with just the one.
- That way, when the repro succeeds, you can easily terminate the locked 'tab' without losing any other tabs/windows/etc.
2. _**Immediately**_ click on the "Return to testing home page"
3. See error - the page will go fully unresponsive, the "stop" command won't work, and you'll eventually see something about how "This page is slowing down Firefox down. ..."

If it doesn't trigger, just try again faster. It's _very_ consistent in Firefox when you can click the link quickly enough.

**Expected behavior**
Not a deadlock, that's for sure!

---

**KeymanWeb:**
- OS: macOS
- Browser: FIrefox. Does not reproduce in Chrome.
- KeymanWeb Version: 15.0.260
- URL: `$KEYMAN_ROOT/web/testing/unminified.html`

**Other notes**
I should point out that searches by keyboard id and language id do seem to complete _far_ faster than those by language-name lookup; it _might_ be possible for it to trigger for those two if the browser were experiencing heavy lag. More of an "I can't rule it out" than an "I expect it", though.