Migrate `java.time.format.DateTimeFormatter` to `kotlinx.datetime.format.DateTimeFormat`

[Jolanrensen]

Like the title says, as continuation of #843 we should also update the parser options with the kotlin-first solution.

[Jolanrensen]

Okay, after investigating I've found some key differences between Java DataTimeFormatter and Kotlin DateTimeFormat<T>.

The Kotlin version is typed; each DateTimeFormat<T> is specific to the date-time class it produces, for instance DateTimeFormat<LocalTime> can only produce LocalTimes.

Conversely, the Java version is untyped. A single DateTimeFormatter instance can be used to produce any date-time like class.

One consequence of this difference is not being able anymore to parse different date-time types with a single ParserOptions, like columns with just times and others that have just dates. However, we could solve this by adding a new parser option: dateTimeFormats: List<DateTimeFormat<*>>? = null which would be called in order using parseOrNull.

Another part negatively affected by this difference is our ParserOptions.dateTimePattern argument. This works fine in the Java variant, as it will create one DateTimeFormatter that can be used to parse LocalDates, LocalDateTimes etc.
For Kotlin, this is a bit more tricky. We don't know what the expected date-time type will be of the String.
So, should we call LocalDateTime.Format { byUnicodePattern(dateTimePattern) } or LocalTime.Format...? It would be safer if users specified their desired format and type explicitly in the new dateTimeFormats argument.
If we do want to keep it, to keep the user-facing API the same, we could simply try the provided pattern for each date-time class we parse anyway and catch the exception when parsing fails.

We would also get an interesting deprecation cycle (note this is just a draft):

Provided Java DateTimeFormatter	Provided Kotlin DateTimeFormats	Provided dateTimePattern	Skipping Kotlin DateTime types	Deprecation level	Result
false	false	false	false	-	Kotlinx date-time instance
false	false	true	false	-	Kotlinx date-time instance
false	false	true	true	-	Java date-time instance
true	false	irrelevant; ignored	false	WARNING	Kotlinx date-time instance
true	false	irrelevant; ignored	true	? (should not be WARNING, but not sure how)	Java date-time instance
true	true	irrelevant; ignored	irrelevant; ignored	WARNING	ERROR, cannot have both kotlin and java
false	true	false	false	-	Kotlinx date-time instance
false	true	true	false	-	Kotlinx date-time instance; dateTimePatterns are checked after dateTimeFormats
false	true	true/false	true	-	Java date-time instance, converted from kotlin?

Seems this needs some important decisions to be made:

• Should we drop the java dateTimeFormatter/pattern option? (people might rely on Java DateTime)
• Should we keep or drop dateTimePattern and what should it do for Kotlin/Java?
• We could also rename the old one(s) to "javaDateTimeFormatter"/"javaDateTimePattern"
• How about we automatically parse to Java datetime if a Java DateTimeFormatter is provided and to kotlinx datetime if a DateTimeFormat is provided?
• probably more