Fix iOS text input not working with password integration

[frenzibyte]

• Alternative to / closes Fix iOS text input not working well with password auto-fill integration #11699

Fix text field resetting text when replaced with a short string

When selecting a password to auto-fill in the current text field, the textField.text property is overwritten with that password, and if the password is less than 16 characters, it triggers the code that resets the text content and messes up the entire logic that is supposed to perform backspaces and such.

The fix is to simply reset the text (i.e. fill back the "obligatory for backspace" text) when the event is triggered with a string of length zero, i.e. when the user deletes characters (see docs).

The fix above can be argued to be more of a band-aid than a solid fix, as there's probably no better fix than to rewrite the iOS text input system from top to bottom and introduce text input events when a text is reset or replaced etc. It's a heavy one to discuss and my take on the matter may probably be biased towards iOS or not well thought of, but either way the fix above will do for now.

Work around password integrations hiding software keyboard and preventing autofill

When pressing the "Passwords" button on the keyboard to pick a password from the keychain/vault, the keyboard hides, which triggers the keyboardWillHide animation, and incorrectly stop text input, ultimately not accepting any character entered from the selected password due to the text input being inactive.

My previous attempt in #11699 and also the attempt of using textFieldDidEndEditing both do not work most of the time. For some reason, when the password integration overlay opens, and the user taps the search bar to search for their password, the SDL text field becomes unfocused and the textFieldDidEndEditing gets triggered, without being accompanied with a textFieldDidBeginEditing or the text field gaining focus again. Therefore the text input state becomes deactivated at the point of searching and is never activated back, ignoring any password selected for auto-fill.

As a last resort, this PR makes the assumption that any changes to the text field content could not have happened without the user having text input already active, and so it forcibly activates text input in textFieldTextDidChange momentarily until all relevant text input events are sent out to the game, then text input is disabled again.

[frenzibyte]

An alternative approach that can avoid this workaround would be completely detaching SDL text input state from the visibility of the software keyboard and/or generally the focus state of the text field. I'm not sure if anyone will agree with this approach, so I went ahead with the workaround above for now.