Fix SDL_StartTextInputWithProperties not updating input type on android

[Susko3]

Description

RFC, not final PR. MVP that fixes this on Android.

Fixes SDL_StartTextInputWithProperties so that the requested SDL_PROP_TEXTINPUT_TYPE_NUMBER is always applied. Tested on Android. Previously, if a screen keyboard was already shown (eg. text input already active), the properties would be ignored.

This change allows the following application code to work:

// user clicks a regular textbox so the app starts normal text input
SDL_StartTextInputWithProperties(window, /* SDL_TEXTINPUT_TYPE_TEXT */);
// Android: the screen keyboard is shown and has text type

// some time later

// user clicks a number textbox so the app wants to change the text input type
// importantly, SDL_StopTextInput() was not called
SDL_StartTextInputWithProperties(window, /* SDL_TEXTINPUT_TYPE_NUMBER */);
// Android: the screen keyboard is updated to have number type [fixed by this PR]

Does this series of calls make sense from an API standpoint? Do you think the application should call SDL_StartTextInputWithProperties() → SDL_StopTextInput() → SDL_StartTextInputWithProperties()? (Seems less ideal, as it might flick the keyboard unnecessarily.)

I've not checked that calling ShowScreenKeyboard() when the keyboard is already shown works as expected on other platforms (only Android is tested and updated).

Existing Issue(s)

Calls to SDL_StartTextInputWithProperties when text input is already active will be ignored by android (the keyboard type presented to the user will not change).

• First noticed in Allow TextBox to specify type of text being input ppy/osu-framework#6408 (comment)

[Susko3]

Why was the SDL_ScreenKeyboardShown() check originally here? It was correct for SDL_StartTextInput(), but now that SDL_StartTextInputWithProperties() is a thing, this check no longer makes sense.

If the props have changed, ShowScreenKeyboard (or a new update method) should be called to communicate the updated keyboard type to the platform layer.

[Susko3]

This works, but it shouldn't be called every time. Restarting text input might cause UX problems. Maybe only call it if mTextEdit input type is changed.