refactor: Preparing core module for Compose support

[0ffz]

This PR adds compose multiplatform dependencies and makes small updates to the core module to enable a future kool-compose-ui module to function correctly. I've left comments about some changes below where I'd like some feedback.

Main changes are:

• Exposing mutable child/parents on UiNode and marking it as internal via an optIn annotation (see comments below)
• Adding a global Snapshot write observer, necessary for mutableStates in compose to correctly trigger recomposition before a frame is drawn (see KoolContext)
• Adding compose dependencies via version catalog

[0ffz]

This is the dependency I mentioned for some compose helpers, repo here: https://github.com/0ffz/compose-mini. I've tried to split things into modules where it makes sense and support all the current targets, the only thing it's necessary for in the core module is a cross platform nanoTime implementation which I've included in the runtime module, so I'd like to hear your preferences:

• I can split just nanoTime into its own module under this repo or leave it as is (the runtime just contains some helpers for creating a composition)
• I noticed Kool already has a SystemClock implementation though this doesn't expose nanoseconds. I could update its implementation, it's not too bad for jvm/web but there are a lot of native implementations if Kool ever adds those targets.

[fabmax]

I think adding it to Time should be fine. I think SystemClock actually isn't really needed anymore since Clock.System made it it to stdlib. So Time.kt could now look something like this:

val precisionTime: Double get() = nanoTime / 1_000_000_000.0

val nanoTime: Long get() {
    val now = Clock.System.now()
    return now.epochSeconds * 1_000_000_000L + now.nanosecondsOfSecond
}

[0ffz]

Updated the implementation to use this and removed the dependency in core module 👍

[0ffz]

Need UI surfaces to be able to access this in the compose module, not sure if keeping it in Time is the best since this may feel like a redundant way to listen to new frames (given we have a flow), I've tried to explain it in the KDoc.

[fabmax]

Hmm yeah seems a bit redundant indeed. I think I would prefer it to be in a more UI specific place and / or maybe have it renamed to something like composeFrameClock or so.

Another option might be to somehow merge it with frameFlow? Not sure if that's actually possible though

[0ffz]

I think it should be doable with just the flow, but there's some extra work to make sure the collection gets dispatched in the right order (it might just mean calling KoolDispatchers.Frontend.executeDispatchedTasks() twice), as well as making sure the value is emitted in the right place.

I think to avoid changing too much I'll leave it with this and annotate it as internal for now.