Kotlin datetime format

[Jolanrensen]

Fixes #876

Changes parsing behavior for kotlin and java date-time, allowing both to be parsed in a more explicit and predictable way.

API changes:

• ParserOptions has changed and gained DateTimeParserOptions. GlobalParserOptions have also changed.
• col.convertTo<>()/df.convert {}.to<>() can now always take ParserOptions, and we gained a handful of new shortcuts and ones that had java arguments but returned kotlin types were deprecated.

See new kdocs and commit messages for specifics :)

Needs to be followed up by #1798

[Jolanrensen]

Uhm okay, so the basic new logic is as follows:

We've got three "modes": JAVA_TIME (only parse to java-time types), KOTLIN_DATETIME (only parse to kotlin(x)-datetime types), null, just try them all, but prefer kotlin types.

You can add formats (by type) to customGlobalDateTimeFormats or customGlobalJavaFormatters. If they are detected, they will be attempted first when parsing.

After both those have been checked, only then do we check the defaultDateTimeFormats and defaultJavaFormatters when parsing.

(Locale will now always be taken into account when parsing to java types)

If the user specifies their own custom format(s) or patterns using ParserOptions, all default and global formats will be ignored and only those from the provided ParserOptions will be used. This automatically limits it to either KOTLIN_DATETIME or JAVA_TIME mode.

Conversions from String to any DateTime type will be Kotlin only for now, allowing you to specify a DateTimeFormat with the correct type (or a pattern as shorcut).

TODO: Find a better way to instantiate a correct ParserOptions. I now have about a dozen constructors which is hard to maintain or work with. maybe a subclass? ParserOptions(dateOptions = KotlinDateOptions()) or JavaDateOptions() maybe?

Edit: slightly outdated

[Jolanrensen]

I probably should remove this check... It would make:

df.convert { javaDateCol and stringCol }.to<LocalDate>(parserOptions)

crash