Keyboard protocol spec: clarify associated text

[rockorager]

Is your feature request related to a problem? Please describe.
The spec for keyboard encoding does not define what text should be considered "associated text".

Describe the solution you'd like
Update the spec to define what is considered "text". I'm not a unicode expert, but most libraries provide some sort of "is_printable" type function which generally (from my quick perusing) is anything in the General category, sans control characters (https://www.unicode.org/reports/tr44/#General_Category_Values)

Describe alternatives you've considered
alacritty is the only terminal with a current issue here. Previously, wezterm had an issue but it was fixed.

Additional context
None

[rockorager]

I should say: my assumption is that control characters shouldn't be considered as text (backspace, tab, enter as very obvious examples). Maybe that isn't correct. I don't care either way, just want clarity :)

[kovidgoyal]

If you have some concerns with my fix, feel free to say so.

[kchibisov]

Should the associated text be also reported if I have a text outside the said range, but I have e.g. Alt+Shift+something pressed? I know that some users don't expect associated text when you have non-empty modifiers with the exception of shift.

[kovidgoyal]

As long as the text has no control codes in it, it should be reported.
For example on macOS Alt (option) is used to generate accented chars,
they must be reported. Many systems have some kind of modifiers used as
part of "compose key" based input.