nk_do_edit cut and copy handler passes len as grapheme cluster count to nk_plugin_copy not as count bytes in const char*

Hello,
all demos handle the len parameter of the `typedef void(*nk_plugin_copy)(nk_handle, const char*, int len);` callback interface as number of bytes in a const char* null terminated C string excluding the nul terminator. But the cut & copy handler code snippet in `nk_do_edit()` actually passes the count grapheme clusters rendered.

```
int b = edit->select_start;
int e = edit->select_end;

int begin = NK_MIN(b, e);
int end = NK_MAX(b, e);
text = nk_str_at_const(&edit->string, begin, &unicode, &glyph_len);
if (edit->clip.copy)
edit->clip.copy(edit->clip.userdata, text, end - begin);
```

In case of muti-byte encodings like utf-8 this leads to corrupted strings.

In case the `nk_plugin_copy` callback interface presents text as utf-8 encoded to the user, then the len parameter is currently wrongly set inside `nk_do_edit()`. In case len should represent glyph count, then multi-glyph or accented grapheme clusters are not supported.

In case it is guaranteed by design that `nk_plugin_copy` passes utf-8 encoded nul terminated string in its `const char*` anonymous parameter, then it is proposed to set len to number of bytes in the nul terminated string. In that case most of the existing demo backends would probably handle the `len` parameter correctly as most simply handle `len` as count bytes.

Start with the nk_plugin_copy typedef and the cut-and-copy path in nk_do_edit(), then compare how the demo backends interpret len. Done means the callback length convention is settled and cut/copy handles UTF-8 text consistently without corrupted strings.

Written by the indexing model from the issue text.