Align folder structure to support commonizer / IDE Plugins

[cmelchior]

We should align how we structure the multiplatform code in the best way, both so it is easy to share code, but also so it is supported by IDE plugins. Right now we seem to do a mix of naming with darwinCommon instead of nativeDarwin.

https://kotlinlang.org/docs/mpp-share-on-platforms.html#share-code-in-libraries contains a description of how code could be organized, but there is concern IDE plugins do not support the same structure. We need to investigate this.

See also https://youtrack.jetbrains.com/issue/KT-40975

No matter the approach we should document it in our README somewhere.

[rorbech]

As part of making a separation of infrastructure code and actual tests I tried to reorganize the source sets of test in #155. The main obstacle of making a shared nativeDarwin source sets is that the IDE doesn't seem to resolve the symbols from the native libraries. It is stated as a limitation in https://kotlinlang.org/docs/mpp-share-on-platforms.html#use-native-libraries-in-the-hierarchical-structure, but unclear whether it is outdated as it actually compiles. It's is just the IDE that doesn't resolve the symbols. This is annoying enough as it prevents discoverability through type ahead find, etc.

I ended up placing the common code in one of the source sets for the explicit target mentioned in the platform definition

kotlin {
    iosX64("ios")
    macosX64("macos")
    sourceSets {
        val macosMain by getting
        val macosTest by getting
        getByName("iosMain") {
            dependsOn(macosMain)
        }
        getByName("iosTest") {
            dependsOn(macosTest)
        }
    }
}

And added that source set to the other platform too. This makes the IDE pick up the symbols and also seem to compile - but can of course not be used where the two implementations differs.

[rorbech]

Closing as duplicate of #358