Upgrader detects that if some type have constraints and their container
type also have constraint, it's not needed to check again this type
because since checkConsistency is recursive when the container is
checked they will also be checked.
This fails when we have situtations like:

  X is allowed in Y
  X is allowed in Z

and there are constraints for by X, Y and Z.
This was raising a KeyError when pop'ing Z :

    Module script, line 50, in Base_getConstraintTypeListPerPortalType
     - <PythonScript at /erp5/Base_getConstraintTypeListPerPortalType used for /erp5/portal_alarms/upgrader_check_pre_upgrade>
     - Line 50
      type_list = constraint_type_per_type.pop(allowed_content_type)
    Module AccessControl.ZopeGuards, line 104, in guarded_pop
      v = guarded_getitem(d, key)
    Module AccessControl.ZopeGuards, line 83, in guarded_getitem
      v = object[index]
  KeyError: 'Z'

In fact, this code is wrong, because if Z is also allowed in W and W
does not have constraint, then Zs inside Ws will not be migrated. In
practice, that's probably OK for now, because we don't use migration
constraints on documents so much, most of the time we only do one
script that checks the constraint globally.