Revert "sql: don't drop table constraints after a nullable UNIQUE" - #39660

Reproduced with the image built from 134006e, whose ddl.rs matches this commit byte for byte, using default (production) flags:

• CREATE TABLE t (a int, CHECK (a > 0)) fails with "CREATE TABLE with a check constraint is not supported ... unsafe".
• CREATE TABLE t (a int, UNIQUE (a), CHECK (a > 0)) succeeds. INSERT INTO t VALUES (-5) succeeds, and SHOW CREATE TABLE still displays CHECK (a > 0).
• With RBAC on, a role that lacks USAGE on schema private can run CREATE TABLE att.t (a int, UNIQUE (a), FOREIGN KEY (a) REFERENCES private.victim (x)). This records a catalog dependency on another role's table, and a plain DROP TABLE private.victim then fails with "still depended upon by table att.t".

The crash that motivated the revert came from changes to nullability and keys. The gate checks can be restored on their own without bringing it back: run the ForeignKey/Check arms in a separate pass over constraints, outside the 'c loop, and leave the key logic and its break 'c as they are. Re-planning existing items at boot stays safe because both flags are enable_for_item_parsing: true (src/sql/src/session/vars/definitions.rs:1995, :2001). Keep the other per-constraint checks that the break skips ("unknown column in constraint", "multiple primary keys") out of that pass. Existing items created through the bypass may break those checks, and they are not flag-gated.