HV-905 Providing a global config for auto unwrapping

An early attempt. Any thoughts on the direction?
> I am not going to guess on what constraints one could come up with. IMO we should not make assumptions in this regards.

This is not about guessing but about understanding what the most common and typical usages of an API are, and making them as easy as possible, while not preventing more advanced use cases ("make the common case simple, make the advanced case possible"). So yes, IMO we should make assumptions about what's going to be used most often in practice and optimize for these cases, while still enabling others.

> Also @NotNull/@Null are probably one of the most used constraints. At least @NotNull.

Agreed. That's why I suggested to require `@UnwrapValidatedValue` in this case where there is an ambiguity. This case will be exactly the same as today, i.e. without `@UnwrapValidatedValue` the wrapper will be validated, otherwise the wrapped element. I only suggest to not require  `@UnwrapValidatedValue` for cases where we clearly and unambiguously can derive that the wrapped value is target of the validation.

> What if case 8 would be made an exceptional case? This would, however, require to have some way for the user to resolve the exception by explicitly applying the constraint on the wrapper.

Can you provide a complete description of the suggested approach and its usage for all the different cases I en-listed? Do you suggest that there is any global switch or not? Summing it up, my suggestion is to automatically unwrap whereever it can be safely assumed (i.e. no global switch to enable this) and use `@UnwrapValidatedValue` only in the case of ambiguities.

> only if the global unwrap flag is set, provided we go this route.

What I meant is, `@Min` targets the wrapped value; Only today it requires `@UnwrapValidatedValue` to be specified, whereas I suggest that this is not required as we can decuct that intend.

> Why? Because you already put meaning into IntegerProperty.

Yes, of course I do. So does everyone who writes or reads code using an `IntegerProperty`.

> It only makes sense if you know what IntegerProperty is.

Right, and users writing and reading that code do know what an `IntegerProperty` is. They don't think of it as a "wrapper" which needs to be "unwrapped prior to validation", they think about it as a numeric bean property which needs to be validated. Naturally they expect e.g. an `@Min` to apply to this value, no matter whether it's a wrapped value or not. Really that's just an implementation detail. E.g. if we provided a dedicated validator for `@Min/InterProperty` it would also work without specifying any additional hints that an unwrapping needs to be done. And from a user POV it's totally irrelevant which way this is done, they just - rightly - expect it to work. That's exactly what I suggest, adhere to the principle of least surprise, make things work as you naturally expect it and resolve situations which are ambigious.

> I think they would. 

Ok, we then have a fundamental different understanding apparently how users work with our library. Would you expect that users would reason any different about the library if we e.g. provided explicit validators for the JavaFX wrapper types?  I don't think they would, as they wouldn't even know whether its implemented via specific validators or an automatically registered unwrapper. Now we agree that the unwrappers are advantegous as they work generically also for custom constraints, that's why we went for that approach. I think that we don't should worsen it again by requiring `@UnwrapValidatedValue` for cases where perfectly can derive it (and wouldn't need it in the first place, if there was a specific validator).

I guess we wouldn't have the entire discussion if there were specific validators, as there wouldn't be the need for "unwrapping". From a user POV it's exactly the same though, they don't really care how that's implemented.

> people might think they put the @NotNull onto the wrapped value

I just think one way or the other must be the default. Using the wrapper in this case seems reasonable to me. If you think it's of any help, we also can raise an exception in this case (validator for wrapped and wrapper is present) and add a boolean flag to `@UnwrapValidatedValue` which then can be used to resolve the case and say whether the wrapper (false) or the wrapped (true) is the target. I'm fine with that as long as we don't require `@UnwrapValidatedValue` to be given in all those cases where it safely can be assumed.

> (after all the un-wrapper is registered).

Which internally done, so users don't really know about it.