bug(web): Investigate handling of tab and newline characters

From reviewing #2546
on testing K_TAB from external keyboard and the interaction with the suggestions

@jahorton writes:
>A few notes:
>
>In-app \n is changing context... but keeping the old text block as a suggestion.
In-app \t isn't emitted; that's why it's not affecting the context.
System-keyboard \t properly shifts focus targets and doesn't affect context. It's a bit of a shame that it's not realizing that it can't actually output text when targeting non-input UI elements, but that never mattered before predictive text... and so it's more that we never implemented anything to prevent it from being an issue with predictive text.
System keyboard \n seems to act the same as in-app \n.
Also, doing a quick test on the KMW predictive text bootstrapping page... that \n behavior shows up there too, unembedded. So, that's not even an Android thing.
>
> ... The \t notes merit work as a separate PR and issue, ...

Start by reviewing issue #2546 and reproducing the in-app and system-keyboard tab and newline behavior in the web client. No source file or test entry point is identified in this issue, so first locate the predictive-text and focus-handling paths. Done means the expected tab and newline behavior is agreed and covered by a separate, reviewable change.

Written by the indexing model from the issue text.