anchor.diff:  
   TODO
   
  -==== Meta-data retrieval
  +==== Metadata retrieval
   
   TODO
   
  
positive.code: 
  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.
  * 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.
  ====
  
  ==== 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:
  
  [source,java]
  ----
  
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:
  
  