Support BOM & suggestion for plugin enhancement

[Omico]

It looks like Jetpack Compose Material 3 and Jetpack Compose Material have different release cycles. Maybe we can get rid of the plugin-defined versions and align with the Compose BOM to create our Compose Multiplatform BOM? Also, releasing the same version makes it much easier to migrate/switch between Jetpack Compose and Compose Multiplatform and can help us more clearly manage the Compose Multiplatform project (merging code from Jetpack Compose).

https://developer.android.com/jetpack/compose/bom/bom-mapping

In my opinion, we can follow the below steps to achieve this:

1. Create a BOM module, merging source code from Jetpack Compose with the same version in Jetpack Compose BOM. We provide the same version as the Jetpack Compose BOM. For example, the Jetpack Compose BOM 2024.01.00 is released with Compose 1.6.0 and Compose Material 3 1.1.2 inside. We merge these versions of code and release our Compose Multiplatform BOM 2024.01.00, Compose Multiplatform 1.6.0, and Compose Multiplatform Material 3 1.1.2. Through this, users will know the specific version they are using. If we apply bug fixes or improve multiplatform support, we can release versions like Compose Multiplatform BOM 2024.01.00.1, Compose Multiplatform 1.6.0.1, and Compose Multiplatform Material 3 1.1.2.1. (The core concept is not to break the API changes)
2. Spereate the Compose Multiplatform Gradle plugin release cycle and align it with the Compose Multiplatform Compiler and Kotlin versions. So that users can always get the latest Gradle plugin to use. We can also print suggestions for the newest version through the Gradle plugin. (Also can popup from Compose Multiplatform IDEA plugin)

[mazunin-v-jb]

Hello! Thank you for the issue, I'll pass it to the team.

[Omico]

Hi @mazunin-v-jb,

https://github.com/Omico/compose-multiplatform-omico

I created this project hoping it could provide a little help with this problem, but I can't actively develop it due to personal reasons. But my ambition is to separate the development and release repo. The flat display of changes is more convenient than the Git diff. We can use comparison tools such as Beyond Compare to compare the differences.