refactor(web): unifies touch-layout typing, updating Web to the common/web/types version 🐵

[jahorton]

In order to integrate the Web OSK for our new, upcoming gesture types... Web needs the corresponding type information. Rather than continue to keep the touch-layout typing WET, I've put in the work necessary to have Web use the definitions from common/web/types - meaning KMW will now use the same type specifications as Developer's Web-keyboard compiler. (With minor extensions for post-processing.)

There were a few rough edges to resolve in doing so, but it also provided a wonderful excuse to take care of a few longstanding nits we've had. In particular, Web finally gets to say farewell to string form pad, width, and sp typing - though it keeps the legacy-friendly sanitize methods that enforce the correct typing via Number.parse.

The main benefit: Web now has access to flick and multitap layout-spec data, which I'll need for upcoming work.

This was motivated by follow-up work to #9657, but since that starts ripping apart KMW's OSK to the point that certain integration tests will be failing, it's probably clearer for the review process (and for management checks) to 'base' it just before that point.

@keymanapp-test-bot skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

[jahorton]

/common/web/keyboard-processor/build.sh build will run into a build error within this file if this line is not present. (The file references the URL type, which is the cause.) It apparently doesn't matter that keyboard-processor doesn't even touch or import anything from the file; it's just a mutual export alongside the ones we do want, and that's enough to cause the issue during TS compilation.

keyboard-processor compiles without access to the DOM libraries except where made explicit.

This is the only change made in this PR to common/web/types.

[mcdurdin]

Hmm, @srl295 I think we should pull URL usage out of this module and have a helper instead. It's apparently used in 4 places altogether in unit tests and kmc:

• kmc buildTestData/index.ts
• kmc BuildLdmlKeyboard.ts
• unit test: reader-callback-test.ts
• unit test helpers/index.ts

Propose the following:

static get defaultImportsURL() {
  return ['../import/', import.meta.url];
}

And in usage:

    readerOptions: {
      importsPath: fileURLToPath(new URL(...LDMLKeyboardXMLSourceFileReader.defaultImportsURL))
    }

[jahorton]

I presume that'd be a separate issue, not something I ought do here?

[mcdurdin]

Yeah it could be a separate PR. Be good to address it before this change lands in master though, just for cleanliness.

[jahorton]

Up as #9788.

[mcdurdin]

Looks pretty good, just a couple of suggestions really, and an alternate way of solving the /// <reference> in common/web/types which I think is probably cleaner

[mcdurdin]

Hmm, @srl295 I think we should pull URL usage out of this module and have a helper instead. It's apparently used in 4 places altogether in unit tests and kmc:

• kmc buildTestData/index.ts
• kmc BuildLdmlKeyboard.ts
• unit test: reader-callback-test.ts
• unit test helpers/index.ts

Propose the following:

static get defaultImportsURL() {
  return ['../import/', import.meta.url];
}

And in usage:

    readerOptions: {
      importsPath: fileURLToPath(new URL(...LDMLKeyboardXMLSourceFileReader.defaultImportsURL))
    }

[jahorton]

TODO:

• Refer to fix(common): don't use URL in common/web/types #9798.

[mcdurdin]

LGTM, noting that the validation in oskSubKey ll.27-33 is re-corrected in #9804.