add support for cstring, seq[char] and openArray[char] as input string

[gpicron]

[treeform]

Although I would like to support cstring, seq[char] and openArray[char], I do feel like that it makes code and documentation more complex. I can't think of good cases where you would not have a string already or couldn't get one easily.

Do you have a good situation where this matters?

[SolitudeSF]

non-mutable string parameter shouldn't even be allowed when openArray[char] exists

[gpicron]

Although I would like to support cstring, seq[char] and openArray[char], I do feel like that it makes code and documentation more complex. I can't think of good cases where you would not have a string already or couldn't get one easily.

Do you have a good situation where this matters?

cstring is convenient in JS backend has it avoid to convert the whole input to String (utf16 -> utf8) I found it also interesting when getting cstring from ffi linked libs yet in UTF8 (like sqlite). It avoid a copy of the whole cstring to nim string.

seq[char] and openArray[char] is coming from the fact I'm using a libsodium binding. after decryption I have either a seq[byte] or an openArray[byte]. Casting those to seq[char] or openArray[char] is safe when I know by the application that it is a utf8 sequence and avoid a copy to the Nim String. I don't think it is safe to cast a seq[byte] to nim string even if I see it in lot of libs because, up to my knowledge, there is no guaranty the underlying C structs will remain compatible.