Control over configuration and reasonable defaults

[krzemin]

So far we had only one configuration switch that controlled if we look up into default values when performing case class transformer expansion. By default we had this behavior turned on and the user had an ability do disable it using .disableDefaultValues dsl operation.

Considering recent contributions #80 and #81, we have 2 new flags that add some extra behavior around Java beans and optional values in target objects. And here comes the struggling whether they should be turn on by default, which of them and how we want to control the configuration in some wider scope.

One of the proposals would be to have them all turned off by default (that means change to current semantics!) and have the ability to turn them on with a single dsl operation.

sealed trait ExtraBehavior
case object DefaultValuesLookup extends ExtraBehavior
case object JavaBeansNaming extends ExtraBehavior
case object TargetOptionalDefaultsToNone extends ExtraBehavior

obj.into[Target]
  .enable(DefaultValuesLookup, JavaBeansNaming, TargetOptionalDefaultsToNone)
  .transform

// or even passed to `into`

obj.into[Target](enable(DefaultValues, Beans, OptionalDefaultsToNone))
  .transform

As this is breaking change, for least surprise, I would keep .disableDefaultValues in dsl that aborts the compilation with a message that informs about this is not needed any more and that other usages should be properly adjusted.

We could also think about separate configuration object that can be implicitly passed to .transformInto and .into which would allow pre-configuring the library in scope of the whole module or project, in case someone wants to have extras on by default without boilerplate.

[krzemin]

It seems that idea of this DSL when flags are passed as vararg has disadvantage of being hard to discover from IDE. Let's stick to .enableXXX and .disableXXX for a while.