Rename string read/writeUtf8 methods

[fzhinkin]

Closes #155; see the ticket for the rationale.

[whyoleg]

Question regarding Charset parameter position in functions. We have now:

• Sink.writeString(string: String, charset: Charset, startIndex: Int = 0, endIndex: Int = string.length)
• Source.readString(charset: Charset): String
• Source.readString(byteCount: Long, charset: Charset): String
• ByteString.decodeToString(charset: Charset): String
• String.encodeToByteString(charset: Charset): ByteString

What is better:

• what we have now, so Charset is last required argument (in case of writeString), and so f.e. can be even made optional (with default=Utf8) in future if multiplatform Charset will be supported
• put Charset as first parameter in all functions? (as in writeString and readString(byteCount)

Im fine with both variants, just wanted to ask :)

[fzhinkin]

What is better:

• what we have now, so Charset is last required argument (in case of writeString), and so f.e. can be even made optional (with default=Utf8) in future if multiplatform Charset will be supported

I didn't make it optional because there was already a function for writing UTF8 strings. And now, when it shares the name with Charset-based functions, we can encourage users to use a common function for UTF-8 strings instead of a JVM-specific one by requiring explicit charset value in the latter.

Possible future support for our own charsets in IO library is a great argument for supplying default value for the charset parameter, but charsets-support is not even on the horizon ATM, so I don't think it is worth preparing for it right now.

• put Charset as first parameter in all functions? (as in writeString and readString(byteCount)

It looks strange to have a charset as a first parameter there. If we writing a string, then the string should be the first parameter and all other options controlling how it'll be written should follow it, not proceed.