Text_edit ctrl+key isn't working as intended in the sdl3 demo

In the sdl3 demo, the way that ctrl+key functions, select_all, undo, start of line, end of line, ..., etc., are managed causes issue with modded keyboards using macros or with android key boards.

Here's an example of what was happening, pressing `a` would erase all text and write the letter `a` instead, pressing `b` would write the letter `b` at the start of the text area and set the cursor in between the first and second character, pressing `e` would add the letter `e` at the end of the text area.

After some code investigation, I found out that calling `nk_input_key` would always increase `ctx->input.keyboard.keys[key].clicked` even if `ctrl` wasn't push, then if it was released while the clicked counter was still equals to 1, it would increase it to 2 triggering the `nk_input_key_pressed` due to the validation of `if ((k->down && k->clicked) || (!k->down && k->clicked >= 2))`.

In #879 there was a small discussion about it and @sleeptightAnsiC asked me to start an issue to duscuss about it.

I've looked at a few other demos and there's a few that are handled like the sld3 demo—mainly sdl demos—, but there's also a six demos —mainly windows demos—, that filter the `nk_input_key` with ctrl` first.

https://github.com/Immediate-Mode-UI/Nuklear/blob/b5f67b88889e77acde49622747fd73888488db73/demo/gdi/nuklear_gdi.h#L803-L860

I see that they also added `return 1` there, maybe I should add that to the pull requests too.

To answer one of the question from the pull request, The release would be handled only if the letter key is released before releasing control. The problem here is that we should only send a release when the combo was released.

There was also a mention that the `nk_textedit_key` should handle those mods and I'm not sure how this would work, should we call `nk_textedit_key` here instead? Because I know that calling calling `nk_input_key` alone will cause the same issue, unless we need a fix inside nuklear.h to manage it properly, does `nk_input_key` need to support a mods enum?

--------

After looking at it in with a deeper understanding of the code, I'm starting to think that we should have something like `nk_input_key_modded`, it would be similar to `nk_input_key` but would change the key `pressed` key state only if the mod is `true` and setup the `released` state only if the key was pressed in the first place. What do you think @sleeptightAnsiC ?

Start with the SDL3 demo's Ctrl+key handling and the nk_input_key and nk_input_key_pressed behavior described in the issue. Compare it with demo/gdi/nuklear_gdi.h lines 803-860 and the other SDL demos, then establish how combo release should be represented and verify that text editing no longer triggers unintended actions on modded or Android keyboards.

Written by the indexing model from the issue text.