Fix deserialization of un-annotated Option[Trait] fields

[ypoluektovich]

See issue #382.

I'm using valueTypeDeserializer.get and then wrap the result in Some, instead of just using map, so that it'd crash if there's no valueTypeDeserializer. I don't know if that situation is possible, and there are no failing tests.

[ypoluektovich]

Warning: this breaks deserialization of old JSON strings in which options were wrapped in a list.

[nbauernfeind]

Can you elaborate further on your warning? What did the old serialization look like? What does the new serialization look like?

[ypoluektovich]

Options used to be serialized like this, at least in 2.8.9 (and assuming the ObjectMapper configuration I cited in #382):

[
  "scala.Option",
  {
    "_t": "optional_object_class_name",
    "other_fields_of_optional_object": "..."
  }
]

However, now the OptionSerializer just writes the inner object without any wrapping (again, see the example in the first comment of #382).
Without this patch, OptionDeserializer can deserialize old-style Options, but not new-style ones. With the patch, it's the other way around.
I can try looking for ways to support both, but no promises about when, or whether it's even possible. If it proves impossible, my opinion is that the library should support configuration-less deserialization of the results of configuration-less serialization of the same version of the library.

[nbauernfeind]

This doesn't quite seem right. I believe that this deserializeWithType method is supposed to use the passed in typeDeserializer as an override. I will have to look-through/debug your example/test-case more carefully to see if I can figure out how/why it's passing a deserializer that does not work.

[pjfanning]

I'm considering merging #537 - basically this PR with merge conflicts fixed