chore(web): move KeyboardProcessor.Codes into common/web/types

[mcdurdin]

I suggest that we move codes.ts into common/web/types as a future refactor.

_Originally posted by @mcdurdin in https://github.com/keymanapp/keyman/pull/7809#discussion_r1094022876_

Also, SystemStoreIDs from kbdInterface.ts

[jahorton]

An extension of this, coming out of the big namespace -> module feature branch that just landed (#8560):

@keymanapp/keyboard-processor is practically primed for a split into two components:

• Things reasonable for common/web/types
  • keyboard layout stuff: defaults, the layout JSON -> layout object conversion process, layout-related methods
  • the Keyboard class
  • Codes
  • KeyEvent - as the OSK produces these for consumption by the rule-processor, and likely will produce for other platforms come #5023. (They'd need some sort of structure for user-generated keystrokes... and this is Web's existing one.)
  • Maybe the keyboard harness / loader mechanism
    • I think this item's subject to "we could, but why?" I don't think it fits thematically. Just noting the possibility.
    • If we load a full JS keyboard, even if just as a shell for the visual-layout info, it makes sense.
    • We should be able to just pass the layout JSON at some point instead, at which point the loaders would be unnecessary for common/web.
• Things that should stay separate
  • Generally, kmn-keyboard rule-processing.
  • KeyboardInterface (with its keyboard API funcs)
  • Web's OutputTarget & Transcription subsystems.

There may be a slight bit of work needed, but I remember noticing how split-friendly the package's organization & contents were while converting KMW to its now-ES-module-based form.

[jahorton]

https://github.com/keymanapp/keyman/pull/8056 made related changes in preparation for this - it was made at the time I identified the potential split and started more actively preparing for it.

[ermshiperete]

After discussion moving to A18S7 when @mcdurdin is scheduled to be back.