Implement java.io.Serializable for some of the classes

[dkhalanskyjb]

Implement java.io.Serializable for

• Instant
• LocalDate
• LocalTime
• LocalDateTime
• UtcOffset

TimeZone is not Serializable because its behavior is system-dependent. We can make it java.io.Serializable later if there is demand.

We are using string representations instead of relying on Java's entities being java.io.Serializable so that we have more freedom to change our implementation later.

Fixes #143

[Moozart]

Can you please merge this commit if possible? @ilya-g

[ilya-g]

For better control over serialized representation I would suggest using writeReplace/readResolve with an Externalizable container.

[ilya-g]

We usually use const val for that.

[dkhalanskyjb]

I don't understand the idea. Do you mean that LocalTime should be Externalizable?

From the docs (https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/io/Externalizable.html):

When an Externalizable object is reconstructed, an instance is created using the public no-arg constructor

But we don't have public no-arg constructors. I guess we could do something like class LocalTime { @PublishedApi internal constructor() }, which would make it a public constructor for the JVM, and trick Kotlin somehow to avoid initializing val value: java.time.LocalTime in that constructor, but is it worth it to make such intrusive changes just to support Java serialization?

[akhbulatov]

A very necessary implementation on Android to be able to pass LocalDate/LocalDateTime objects between screens

[dkhalanskyjb]

@akhbulatov, it's not "necessary", just convenient: see #143 (comment)