Add support for platform specific localized display names for DayOfWeek and Month

[adrcotfas]

Hello there,

Some context:

• I'm migrating a project from Android Compose to Compose Multiplatform
• On Android I was using java.time.Month.getDisplayName and java.time.DayOfWeek.getDisplayName and I miss that functionality
• I've added some logic here to retrieve the localized names on jvm and darwin targets using a Locale and a java.time.format.TextStyle inspired TextStyle.

I've added DayOfWeekNames.ENGLISH_NARROW and MonthNames.ENGLISH_NARROW to use together with the ENGLISH_FULL and ENGLISH_ABBREVIATED as fallback for displayName.
These were defined as List<String> because could contain duplicate entries, to not accidentally pass them to the DateTimeFormatBuilder which currently expects different entries for day/month names.

I'm looking forward to your feedback and in the meantime I'll be using this: https://github.com/adrcotfas/kotlinx-datetime-names (there's a demo there).

[dkhalanskyjb]

Hello!

Thank you for your interest. This is a known issue, in fact, the most in-demand one of those we have: #352 We are certainly going to include this functionality in kotlinx-datetime.

The code in your pull request fails to build, as the darwin source set inherits from commonKotlin, so it has two actual definitions for Locale. Also, silently defaulting to the English locale on every platform except JVM and Darwin is not consistent with the approach to implicitness kotlinx-datetime takes. The preferred approach is indeed to provide the API only for the actually supported targets specifically, the way you did in https://github.com/adrcotfas/kotlinx-datetime-names/blob/d186a8178cde4527d835d8c5f0515c1fc9dc4b64/library/build.gradle.kts#L19-L44

More importantly, the proposed API is completely unlike the one we would like to eventually provide: see #253. If you prefer the API from this pull request over the one described in the discussion, please let us know in the discussion comments! We'd love to learn more about specific use cases.

Closing the pull request, as it's not the direction we want to take.