Move kotlinx.io.files package to a separate module

[fzhinkin]

Move all filesystem-related functionality to a separate module.

While the library itself is getting closer to stabilization, kotlinx.io.files is getting closer to a trash bin.
There's no way existing filesystem-related functionality will be stabilized. Instead it will be deprecated and replaced with a (hopefully) better API.

With a separate module, it'll be easier to manage different stability and depreciation levels.

Closes #319

[whyoleg]

JIC: there is one usage of kotlinx.io.files in ktor production code (not in tests) blindly (not thinking about consequences) introduced by myself in ktorio/ktor#4192
It was needed to not reimplement this from scratch (or copy from kotlinx-io) for js/wasm-js targets - previously it was just expect/actual
Probably it's better to drop this usage in ktor to avoid breaking changes? cc @e5l

[fzhinkin]

In short term, the change should not break Ktor as long as a new artifact is added to dependencies.

[fzhinkin]

One of the questions still opened for me is the name of a new module. It should include something like -legacy in its name. Otherwise, we'll have to put the future filesystem API into kotlinx-io-filesystem-2/kotlinx-io-filesystem-new module 😞 .

WDYT?

[shanshin]

LGTM

[shanshin]

One of the questions still opened for me is the name of a new module. It should include something like -legacy in its name. Otherwise, we'll have to put the future filesystem API into kotlinx-io-filesystem-2/kotlinx-io-filesystem-new module

if we create a module with a different name, will we have two filesystem modules with a different name at the same time?
Why can't we use different package names?

[fzhinkin]

@shanshin

if we create a module with a different name, will we have two filesystem modules with a different name at the same time?

Yes, we will.

Why can't we use different package names?

It's always an option.

[fzhinkin]

One of the questions still opened for me is the name of a new module. It should include something like -legacy in its name. Otherwise, we'll have to put the future filesystem API into kotlinx-io-filesystem-2/kotlinx-io-filesystem-new module 😞 .

Ok, so we'll have to use different package names anyway and having both the legacy and a new API inside a single module will ease the migration as we'll be able to supply deprecation with a meaningful replacement expression.

[fzhinkin]

Ok, the current approach with the module (and its name) looks fine: we'll add a new API into it, that'll unlock easier migration compared to two separate artifacts.