Serializable DDL

This is an initial discussion of what behavior "Serializable DDL" might have in PostgreSQL.

Notes:

 - Right now, when two serializable transactions run, you can have t1 begin first, then t2 starts and creates a table, t2 then commits.  t1 started first, and so it can't see the new table's entry in pg_class, but because we use "SnapshotNow" for table lookups, t1 can actually select from t2's new table.
 - We have to address the issue of FKs being added against existing tables, or even being for new tables, and what the "right" answer is
 - We already have some mechanics to deal with indexes being added and keeping them from being visible "too early" (indcheckmin)
 - We may have to add similar mechanics for constraints, again, to avoid them being visible "too early"

What needs to be visible immediately and what doesn't?