feat(developer): Provide Access to "Underlying" Key Position

### Is your feature request related to a problem? Please describe.

This is a request to provide support for setting text in the "underlying" location of a mobile keycap. The key labels are associated with the `K_` identifiers, which some mobile layouts use only partially. The keyboard designer may still want to display the _positional_ underlying key label to aid the user, or the label is still mnemonic, but the designer had to work with `T_` or `U_` style identifiers for other reasons.

## Some examples

In the following screenshot (from GFF Amharic Classic), the underlying keys are displayed in the *hint* position as a work-around to the above problems. In a few cases, it would be desirable to display a 3rd character in the hint position (ጽ on the ስ key, ሕ on the ህ key), but doing so leads to severe crowding in the hint position. Setting the underlying Latin letters in the corner would avoid the crowding:


Another example is with the Geezword Tigrinya keyboard, where the labels are desirable throughout, but the author has relied on many `T_` identifiers, and the label mapping is lost. The ability to set them manually via the KMD interface would allow for a better, more consistent, presentation to the user.


### Describe the solution you'd like

The KMD Touch layout editor gains another per-key attribute field to set the displayed symbol in the top-left corner. When not set, the default can apply as per the `K_` mapping; however, the user should also be able to override the default to display no text (a space symbol entered for the attribute is probably sufficient here).

Naturally, CSS selectors for the position, would also be needed.

### Describe alternatives you've considered

_No response_

### Related issues

_No response_

### Keyman apps

- [x] Keyman for Android
- [x] Keyman for iPhone and iPad
- [ ] Keyman for Linux
- [ ] Keyman for macOS
- [ ] Keyman for Windows
- [x] Keyman Developer
- [ ] KeymanWeb
- [ ] Other - give details at bottom of form

### Keyman version

Any

### Operating system

Android, iOS

### Device

mobile

### Target application

N/A

### Browser

N/A

### Keyboard name

gff_amharic_classic, geezword_tigrinya are the two examples cited, but the issue is applicable to others

### Keyboard version

Any

### Language name

Any

### Additional context

_No response_