Deprecate TimeZone serialization

[dkhalanskyjb]

• Remove the @kotlinx.serialization.Serializable annotation from TimeZone and FixedOffsetTimeZone.
• Deprecate TimeZoneSerializer and FixedOffsetTimeZoneSerializer with a warning.
• Introduce and deprecate the .serializer() functions in their companion objects with a warning. Previously, this function used to be generated by the kotlinx.serialization compiler plugin.

Fixes #576

[sandwwraith]

IIRC, we can leave only the start date, not the end date

[dkhalanskyjb]

We can remove the copyright notices completely: Kotlin/kotlinx.coroutines#4016

[sandwwraith]

id String sounds weird. Maybe you want id: String? Or since this is more of a text message, string id sounds better IMO

[sandwwraith]

Note that the moment you remove @Serializable(with=...) annotation from type, it is shown as red with SERIALIZER_NOT_FOUND where it was used in any @Serializable user class. Sadly, we do not have any kind of deprecation migration for that; so I suggest raising all @Deprecated here to ERROR just to speedup this process

[dkhalanskyjb]

The idea is to keep it WARNING for now so that people can work around the SERIALIZER_NOT_FOUND issue by adding their own annotation to the TimeZone field. Then, after a migratory period, when we expect such annotations to be removed as well, the deprecation can be promoted to ERROR.

Does this approach make sense?

[sandwwraith]

I think most of the people wouldn't be able to guess that red code with deprecation forces them to use @Serializable(TimeZoneSerializer::class) (also with deprecation). But let's try, there's hardly another approach if you do not want to skip WARNING stage.

[sandwwraith]

Although I would still advocate going directly to ERROR as kotlinx-datetime is still 0.x and we are breaking binary compatibility anyway (missing @serializable would lead to linkage errors, as we try to access TimeZone.Companion.serializer() which would be gone) (upd: I saw you addressed this)