anchor.diff:  
   When detecting a type-level constraint or cascade, the applicable extractor is determined as follows:
   
  -* Chose the most specific extractor matching the type parameter in question; an extractor A is more specific than another extractor B if A extracts a subtype of the type extracted by B.
  -* If there are several extractors which are equally specific, a `UnexpectedTypeException` is raised. TODO: apply rules similar to "ConstraintValidator resolution algorithm".
  -* When obtaining the extractor for type-parameter constraint validation, the declared type of the validated element is used. This is to be consistent with constraint validator resolution, which is based on the static type of elements, not the runtime type.
  +* Choose the most specific extractor matching the type parameter in question; an extractor A is more specific than another extractor B if A extracts a subtype of the type extracted by B.
  +* If there are several extractors which are equally specific, an `UnexpectedTypeException` is raised. TODO: apply rules similar to "ConstraintValidator resolution algorithm".
  +* When obtaining the extractor for type parameter constraint validation, the declared type of the validated element is used. This is to be consistent with constraint validator resolution, which is based on the static type of elements, not the runtime type.
   * When obtaining the extractor for cascaded validation, the runtime type of the cascasded element is used. This is to be consistent with the rules defined for property path construction which are based on the runtime type.
   
   [NOTE]
   .Implementation note
   ====
  -As extractor retrieval for type-parameter constraints is done using the static type of constrained elements, the retrieval can be done once at initialization time and then be cached. This is not possible for retrieval of extractors for cascaded validation.
  +As extractor retrieval for type parameter constraints is done using the static type of constrained elements, the retrieval can be done once at initialization time and then be cached. This is not possible for retrieval of extractors for cascaded validation.
   ====
   
   ==== Applying element-level constraints to wrapper elements
   
  -Sometimes there is no type-parameter to put a constraint to, but still constraints should be applied to the wrapped value instead of the annotated element. JavaFX's property hierachy falls into that category, as it defines specific `Property` sub-types which are not generic:
  +Sometimes there is no type parameter to put a constraint to, but still constraints should be applied to the wrapped value instead of the annotated element. JavaFX's property hierachy falls into that category, as it defines specific `Property` sub-types which are not generic:
   
   [source,java]
   ----
  
positive.code: 
  Assuming there is no dedicated extractor for `CrazyMap` but only the default ones for `K` and `V` of `Map`, extraction for `@RegExp` must happen via the default map value extractor and extraction for `@Min` via the default map key extractor.
  
  A type-parameter in a sub-type may also map to several type-parameters in a super-type:
  
  [source,java]
  ----
  interface NumericMap<T extends Number> extends Map<T, T> {}
  ----
  private NumericMap<@Min(1) Integer> integerMap;
  
  The `@Min` constraint is to be applied to the map' keys and values as the annotated type parameter maps to `K` and `V` of `Map`.
  
  * Type-level constraints can be applied to the elements of `Object` arrays and arrays of any primitive type:
  
  
negative.code: @Valid List<Order> orders;
  ----
  
  This would also validate any constraints on a custom list type (e.g. `MyList#getId()`). TODO: we never clarified that in 1.1. Should it be made explicit?
  
  * Map validation with type-level constraints and cascading:
  
  