anchor.diff:  [NOTE]
   .Motivation for callback-style API
   ====
  -Instead of returning the extracted values from the method call, implementations of `ValueExtractor` pass the extracted values to the given receiver callback. This helps to avoid object allocations and allows to handle the case of a single extracted value (`Optional<T>`) and multiple extracted values (`List<T>`) in a uniform fashion.
  +Instead of returning the extracted values from the method call, implementations of `ValueExtractor` pass the extracted values to the given receiver callback.
  +This helps to avoid object allocations and allows to handle the case of a single extracted value (`Optional<T>`) and multiple extracted values (`List<T>`) in a uniform fashion.
   ====
   
   ==== Default extractors
  
positive.code: 
  [NOTE]
  ====
  This implies that there may not be more than one extractor for a given generic type. I.e. there can be an extractor for `List<?>`, but not one for `List<String>` and one for `List<Integer>`.
  ====
  
  In some cases, an extractor applies to the entire extracted type itself (e.g. for arrays). In this case the `@ExtractedValue` annotation is to be given on the extracted type itself:
  
  [source,java]
  ----
  
negative.code: private CachableValue<@Min(1) Integer> foo;
  ----
  
  Validation of `foo` will fail, as none of the two matching extractors is more specific than the other one.
  An extractor for `CachableValue` must be added, resolving the ambiguity.
  
  ==== XML based configuration
  
  