bug(developer): mismatch between KMW-keyboards' stub font and touch-layout font

This is for the Developer side of #10524.

> We have a number of published keyboards in which the touch-layout has one setting/name for the keyboard's font while the package and/or stub uses a different name for the font.

> A prime example of an affected keyboard: `sil_euro_latin`
>
> _Touch layout_:
>
> ```json
> "font": "DejaVu Sans",
> ```
>
> _Actual stub from the KMW Cloud API_:
>
> ```json
> "font": {
> "family": "LatinWeb",
> "source": ["DejaVuSans.ttf", "DejaVuSans.mobileconfig"]
> }
> ```
>
> `LatinWeb` will properly link the font - as that's what the stub calls it - while `DejaVu Sans` will _not_.
>
> Attempts to investigate this lead me to a question - where does that `LatinWeb` bit _even come from_? I don't see any evidence of that string within `sil_euro_latin.kps`!

In 16.0, the `LatinWeb` font-family name returned by api.keyman.com stubs is sourced from hand-written `.keyboard_info` files. We're doing away with that in 17.0... by dynamically generating a name for the font entries seen in the `.kps` - which themselves have no guarantee of matching what's set in the touch-layout file.

My personal take: we should deprecate the field seen in the touch-layout field and indicate that it will always be ignored in favor of what's set in the .kps. I believe the "source of truth", from a user perspective, would thus be here:


My inference is that the fonts available in the drop-down are selected from any available within the package's included files... but I'm not sure if _that_ aspect of my analysis is correct.