Use IOException provided by kotlinx-io

[twyatt]

This change comes with some tradeoffs:

One one hand, we get to leverage a widely used class signature for IOException, that consumers may already use — reducing overhead of having to keep Kable's (com.juul.kable.IOException) vs. kotlinx-io's (kotlinx.io.IOException) separate. In other words: it is a footgun for consumers that use kotlinx-io, as they may try to catch kotlinx.io.IOException when calling a Kable IO function (not realizing that com.juul.kable.IOException will slip right through that try-catch).

On the other hand, this pulls in a library purely for a single exception class (this would likely be justified if we started adding support for kotlinx-io features, e.g. Source, Sink, Buffer; but that is a long ways off, if ever).

Of further consideration: there is talk of moving some of these IO primitives to the standard library (Kotlin/kotlinx-io#354). It is unclear if that would include IOException — if IOException were moved to the standard library it would be a no brainer to use it.

[cedrickcooke]

I don't think we should hesitate about including a large library and only using a subset of it. All 3 major KMP targets include dead code elimination in their release process (KMP handles it directly when building native/JS, and Android has it through R8)

[QuantumRand]

This actually paves the way nicely to be able to add an optional kotlinx-io sub module that provides things like Sink, Source, and Buffer features.