generify tristate module as reusable module

[myuwono]

In this PR

• introduce GenericTriStateModule<T> as a base of tristate (undefined | null | value) serde.

fixes #107

Context

There are times where users need to model an API that need differentiate between:

• absence of a field
• presence of a field in json, but being set to null
• presence of a field in json, with a value set

Option is a very specific case of the above where both absence and presence of a field with a null value indicates a None.
However it's important to note that these generalizations sometimes do not apply. For instance for PATCH endpoints where null means remove, and undefined means do nothing. In this PR we're extracting out this functionality as a separate module that users will be able to customize to support their requirements accordingly.

An example usage of the GenericTriStateModule<T> to form an option module is as follows:

val optionModule: GenericTriStateModule<Option<*>> =
  GenericTriStateModule(
    serializationConfig =
      GenericTriStateSerializationConfig(
        isPresent = { it.isDefined() },
        serializeValue = { option ->
          option.fold({ SerializedValue.AbsentOrNull }, { value -> SerializedValue.Value(value) })
        }
      ),
    deserializationConfig =
      GenericTriStateDeserializationConfig(
        ifAbsent = { None },
        ifNull = { None },
        ifDefined = { it.some() }
      )
  )

Out of scope

• Defining a data model specifically for tri-state still need to be discussed with the team

[i-walker]

All these public members in this file need to have a deprecation cycle

[myuwono]

Thanks @i-walker that's a really good point. I'll defer the refactoring of option module as another issue entirely. I think several of these modules access modifier shouldn't have been public. I'll address that separately after this PR.