Change project build structure and use version catalog for storing dependencies

[bejibx]

Fixes #46. Sorry I did not discussed these changes with you ahead of time. I'm completely ok with you discarding this PR because I did this mostly as an exercise in gradle configuration. So mostly what I've done is:

• replace buildSrc with included build
• refactor convention plugins
• move all dependencies and versions into libs.versions.toml

Ok, now for some implementation details.

Convention plugins now organized into 3 different categories: base, component and feature. Base plugins just contains some reusable build logic for component plugins. Component plugins configure project modules. Feature plugins configure separate build features. I'm also rearrange plugin hierarchy a bit. Namely kmp-library (successor of kmp-library-conventions) plugin now not applying publishing-conventions. Did this because publishing seams to me like a feature which component could have or not.

Pretty much all versions are now listed inside version catalog with few small exception due to the fact that it's impossible to use generated catalog accessors in convention plugins. Plugin versions are declared by including concrete plugin dependencies inside root build.gradle.kts in included build. I don't use plugin aliases because in my experience their usage is problematic, especially with kotlin plugin (see gradle/gradle#17968 for example).

I switched from extension method to convention plugin for target configuration inside kmp library modules. Firstly, I made attempt to make target ignoring syntax similar to how we adding new targets in kotlin multiplatform plugin. Secondly, for configuring actual ignored targets I have to add plugin extension and it was quite tricky to figure out how to configure targets from convention plugin and, at the same time, get fully configured extension from the build script apllying this plugin. It seems gradle have no way to await specific extension configuration, my first solution was to configure targets in afterEvaluate {} block but later I tried another approach - to initially add all targets and remove them by name while subscribing to property changes in plugin extension and to my surprice this seem to work. I don't really like this solution but after reading a TON of forums, github issues and slack conversations it seems there is no idiomatic way to sync configuration phases between convention plugin and extensions in consumer plugin. Either this or afterEvaluate {} and everybody saying afterEvaluate is bad (duh).

I had to update some deps in the process, most notably:

• kotlin-stdlib:2.0.20 -> kotlin-stdlib:2.0.21 (and all other deps configured by kotlin gradle plugin)
• kotlinx-coroutines-core:1.9.0-RC.2 -> kotlinx-coroutines-core:1.9.0
• gradle-wrapper:8.1.1 -> gradle-wrapper:8.11.1
• symbol-processing-api:1.9.10-1.0.13 -> symbol-processing-api:2.0.21-1.0.28
• dokka-base:1.9.0 -> dokka-base:1.9.20 (plus transitives but this should not affect main build)

I ran all unit tests locally, all seems green. My main concern is I don't know how to check if publication stuff still working as intended. Can I somehow test this on my side or will you help me to check?

[bejibx]

I also had problems with compilation after removing casts to KProperty1 in ValidatableTest despite my IDE compiler was pretty sure those casts were unnecessary (and project was alredy using kotlin version 2.0.20). I was able to fix this in c8ad3f4, what do you think? Looks like method api should stay the same

[bejibx]

Reverted my changes regarding definitely non-nullable types.

@nesk Is there any chance you'll be able to look at this PR anytime soon and provide some feedback?