This comes out of a design philosophy review on what we include when we
embed OSK data into KMX.
We will now avoid embedding font name into the OSK (and hence .kmx)
altogether, and leave that metadata to the packaging data. Reasons:
1. The font information is specified in the .kps, so we have to do a
patchup on the .kmx during packaging if we want to embed the info
into the OSK.
2. The referenced font must be supplied separately anyway (via .kmp,
@font-face, or system supplied, etc), so including the font facename
in the keyboard is not really all that helpful.
3. Philosophically, the font is really a presentation level factor
(aside from displaymap considerations). Keeping it together with
future theming and styling choices, rather than the key layout data,
seems appropriate.
4. This makes fewer places where font data is referenced -- in fact, to
just one place: in the .kps/.kmp for LDML keyboards, which is great.
This also simplifies some aspects of the embed-osk-in-kmx work, removing
the need to patch the .kmx after the build, and eliminates the smelly
kmx-plus-osk-token.ts file.
A corresponding change has been made to the design document referenced
in #14857.
Test-bot: skip
The disp and layr sections have new v19 layouts, to support the Keyman
OSK requirements for epic/embed-osk-in-kmx. This supports writing the
new versions of these sections in Developer and loading them into Core,
doing transformations where necessary so that Core always works with v19
structures after load.
This does not implement the transformations required to support the OSK
APIs; that will be implemented in a follow-up PR. Nor is support for
writing the OSK data from source .kvks and .keyman-touch-layout
supported; this is just the scaffolding for supporting the structures in
the KMX+ data.
Test-bot: skip
