Fix insert replace reset etc.

[rswinkle]

This pull request does a few things:

1. Adds support for INSERT/REPLACE/RESET key inputs to all backends (except rawfb). Despite INSERT and REPLACE being treated as separate keys by Nuklear, I made them use the Insert key as a toggle similar to other word processors. This involved changing the behavior in the 1 or 2 backends that already had it. ESC is RESET for everything. I did not build/test the windows backends.
2. In the process I found several issues in a couple backends. I added some other keys when I noticed and completely fixed Allegro's broken behavior (It now correctly does key repeat behavior for special keys/combos like BACKSPACE, DELETE, the arrows, etc.
3. Minor modification to Nuklear itself, allowing you to switch between directly between insert and replace/overwrite modes directly rather than having to reset back to VIEW mode first. This again matches other editor behavior and is far more intuitive.

In the process of making these changes I needed an input field where I could actually test it since the default types EDIT_SIMPLE, EDIT_FIELD, EDIT_BOX all include ALWAYS_INSERT_MODE. So I added a field to the overview demo.

This brings me to some other changes I want to make to Nuklear. Let's see if
I can decide on the best way to describe/design this.

I think ALWAYS_INSERT_MODE should really be ALWAYS_EDIT_MODE and allow
switching between INSERT and REPLACE modes but not allow VIEW_MODE. I think
that makes much more sense for the default behavior for EDIT_SIMPLE,
EDIT_FIELD, and EDIT_BOX. Realistically I think that should be the default
behavior period, even if you pass no flags and supporting VIEW_MODE should be
an opt-in not an opt-out decision since it's rare that users would want that
behavior.

On a slightly related note, I noticed a while ago that if you want a text
field that is read only you can't actually use EDIT_READ_ONLY. READ_ONLY
should actually be called NON_INTERACTIVE which seems pointless to me. If
you want that, why not just use a label? Just for the box around it? If
you want the user to actually be able to copy the text displayed
but not be able to change the text you have to do this:

NK_EDIT_SELECTABLE | NK_EDIT_AUTO_SELECT | NK_EDIT_CLIPBOARD;

Granted the AUTO_SELECT is optional. You also need to use a null filter
function (which doesn't exist in Nuklear though I think it should):

nk_bool
nk_filter_nothing(const struct nk_text_edit *box, nk_rune unicode)
{
    NK_UNUSED(unicode);
    NK_UNUSED(box);
    return nk_false;
}

I think we should have READ_ONLY have the behavior above, and a new flag
NON_INTERACTIVE behave like READ_ONLY currently does.

Lastly, there is another thing I discovered that AUTO_SELECT does not imply
SELECTABLE which is ridiculous and counterintuitive.

So, I could do/add all of these things to this pull request or create a
separate pull request (or several though I think that's overkill). While all
of these technically change Nuklear behavior (even the pull request as it is
now), I don't think it will really affect almost anyone. Most of the changes
are in ways people hardly ever use it (or even couldn't use it considering
none of the backends even supported insert/replace/reset till now).

So whether I continue in this pull request or make a new one, since none of
these change the actual function calls/prototypes I would say they would be
minor changes at most, ie 4.13.0

EDIT: typos