Foreign key support

This is a whole bunch of new code, but it does not break down into pieces very well, except for DDL / DML, which is already separate on file boundaries.

I do not think that there is much risk if one does not define any foreign key constraints. But I still assume that we want to hold off on merging this until after the JDBC release is out.

The general approach:
* Terminology used here is *referencing* and *referenced* for the two ends.
* Foreign keys are available in the AIS on *both* tables. They are serialized on the referencing table.
* Constraints are backed by indexes. Always. On the referenced end, a unique index with the given columns must exist. On the referencing end, a new index is created, even if an equivalent one is declared. (Mostly because this keeps the number of cases in ALTER down. This could be improved at some point.) The new index is marked as a foreign key and thereby protected.
* RESTRICT constraints are checked on the index directly (and immediately in the case of Persistit).
* INSERT / UPDATE referencing: corresponding entry must exist in referenced index.
* DELETE / UPDATE referenced: no referencing index rows match key.
* TRUNCATE referenced: no rows > NULL exist in the index, unless they have NULL is some other column.
* Other actions are handled by operators, which are generated by directly. These use parameters for all the key columns in declaration order, old then new. So, for instance, ```ON UPDATE CASCADE``` is ```UPDATE referenced SET fk1 = $3, fk2 = $4 WHERE fk1 = $1 AND fk2 = $2```. Halloween is avoided by inserting Buffer_Default; the test for when to do this could no doubt be tightened up for performance.
* A Store has a ConstraintHandler, which received callbacks very much like table listeners, but not quite at the same times. As with those, there is an UpdatePre and an UpdatePost. The latter is needed for ON UPDATE CASCADE, since you need to make the changed *after* the key to which they will refer is there.

Shortcoming relative to the standard:
* Does not distinguish between NO ACTION and RESTRICT. Both check constraints right away (or, in the case of FDB, asynchronously but not until any semantic boundary). This mostly makes a different when deferring control is added. But even without it can affect constraints within a single table where a single DELETE statement would kill both ends. Right now, an error may occur if the referencing end is seen first, even for NO ACTION.
* Does not support any MATCH mode other than SIMPLE (any null column means constraint is not violated).

I decided against doing anything about the semantics of GROUPING FOREIGN KEY, which is odd now that it is not enforced. Or about DELETE CASCADE as a single statement, as opposed to the result of the ON DELETE action, since this is about making us more standard and not adding new non-standard syntax.