Kotlin Multiplatform support

[kizitonwose]

The multiplatform calendar library is ready, you can view the sample project online at https://calendar.kizitonwose.dev

Following the discussions at #554, I decided to publish the multiplatform library under a different module name com.kizitonwose.calendar:compose-multiplatform, so the Android view and compose libraries using the java.time APIs will keep existing in their modules com.kizitonwose.calendar:view and com.kizitonwose.calendar:compose respectively. This was done for a few reasons:

1. The Compose Multiplatform library release happens much later after the Android library is released, which makes sense given the work needed to be done by the JetBrains team for multiplatform support. For example, version 1.7.0-alpha01 of the Android compose library was released on 24th January 2024, while version 1.7.0-alpha01 of the compose multiplatform library was released on 3rd July 2024. Historically, every major compose version has introduced a breaking change in the underlying API used for the calendar page snapping logic and required an urgent fix to support users already on the Alpha or Beta Compose version. Moving the compose project entirely to compose multiplatform means such quick fixes would no longer be possible, as Android users would need to wait until the relevant compose multiplatform project is released.

2. I do not want to remove the usage of java.time APIs in the project as they are quite fun to work with. Also, keep in mind that many Android projects out there do not have multiplatform setup, so I do not want to force the library users to use the kotlinx-datetime library. I attempted using expect/actual declarations to see if I can have one compose multiplatform project while exposing java.time APIs for Android projects, but that got messy as I found myself essentially rewriting a lot of date APIs which is going to be troublesome to maintain.

3. Another approach to ensure that the java.time library implementation is available is using generics to create a base calendar implementation and expose what is needed for the java.time and kotlinx-datetime libraries, but this has the problem that library users have to write things like CalendarState<YearMonth, CalendarMonth>, CalendarLayoutInfo<CalendarMonth> all over the place which is not so nice. Also, the view module users will then have to deal with this compose mess which has nothing to do with them since the core model classes are shared across the compose and view libraries.

I concluded that it is easier to just publish a separate artifact for compose multiplatform. Of course, this means that some of the inconvenience saved on the library consumer will be passed on to the library maintainer/developer. However, the library API is quite stable and does not change much, so maintaining the library for java.time and compose multiplatform should hopefully not be too much hassle.