Convert ByteString from/to Int8Array

[fzhinkin]

Closes #268

[lppedd]

This is something that should probably be addressed for all kotlinx libraries: should everyone use these built-in types, which are pretty weird considering we generally don't want anything to do with WebGL, or should they come from kotlin-wrappers, which tend to be the most used?

The question is important because the only "interop" between same types coming from different libs is unsafe-casting.

[fzhinkin]

If an ArrayBuffer originating from kotlin-wrappers needs to be converted to/from ByteString, then it should be done either in kotlin-wrappers, or in a separate library.

[lppedd]

It's reasonable. However I'm thinking that since most people on K/JS are using kotlin-wrappers (and most commonly its kotlin-js module), it would be a surprise to them that the code is red in the IDE when calling Int8Array.toByteString(), for example.

It's a bit of an unfortunate situation because it's all fragmented into multiple places.

1. The org.khronos.webgl package is explicitly documented as a wrapper for WebGL, so the question "why am I using WebGL types?" would come up fairly naturally.

2. The org.khronos.webgl package is a remnant of the extraction (KT-35973) of DOM APIs from the stdlib, and there is also an open issue about moving away from it (KT-57303). So maybe using kotlin-wrapper types ensures better stability on the long run.

I guess the right call would be to have the Kotlin team officially say "we will all use these types for JS", and I guess being kotlin-wrappers is the most complete and up to date collection, that could be the direction. If the stdlib needs a small interop layer, its externals could be made internal.

Anyway, from my perspective, it's all good anyway, I'd just unsafeCast<T>, but it's something I wanted to mention for more clarity.

[lppedd]

since most people on K/JS are using kotlin-wrappers

After using kotlin-wrappers for a while, and after getting rid of them and hosting my own types for compatibility reasons, I think another topic to consider is "multiplatformability".
By that I mean how easy it is to have a common, let's say, ByteArray that actualizes to an Int8Array under JS, and to other types in other platforms.

kotlin-wrappers typed arrays are now reflecting what TypeScript decided to do, that is, add a generic type parameter:

interface Int8Array<TArrayBuffer extends ArrayBufferLike>

Because of issues such as KT-61043 and KT-60561, having type parameters makes actualization extremely difficult, if not impossible. This is why I had to replace kotlin-wrappers types with my own, or why I'm still using types from the stdlib.

So, I would prefer to use types from the stdlib at the moment, or to use types from kotlinx-browser when they'll be available.