DERBY-6670 Rollback to savepoint allows violation of deferrable constraints

Patch derby-6670-2-c. This patch is a rewrite of the prototype patch
derby-6665-01-ae-deferredCheckAndDroppedFK.diff which moves from using
physical conglomerate ids as keys in the internal identification of
constraints and their indexes for deferrable constraints to

- UUID for the constraints for primary key, unique and foreign key
- UUID for base table (or constraint dependening on where in the code)
  for check constraints

This is essentially only a refactoring which simplifies the code. But
it also makes possible the fix for this issue, which is to stop
removing the deferrable constraint violation information when
constraints are dropped (directory or as a result of the table being
dropped), since a rollback to savepoint might undo drops, at which
point we need the violation information again. The solution is to make
the validation code robust against the absence of dictionary objects
(tables, constraints): if at commit or "set immediate", the objects
are gone we know there is no checking to be done.

The patch also adds rollback to savepoint test cases in
ConstraintCharacteristicsTest#testDerby6670_a, including the repro for
this issue.

Also removed the release of violation information at a successful
change to immediate constraint mode as part of a SET CONSTRAINTS
statement, since a rollback to savepoint might re-introduce the
violations. New test cases added for this, too (#testDerby6670_b).

git-svn-id: https://svn.apache.org/repos/asf/db/derby/code/trunk@1614777 13f79535-47bb-0310-9956-ffa450edef68