Option to use Postgres naming conventions for unique constraints

Currently in Persistent, unique constraints are named after the Haskell name. For example, something like:

ApexPosition sql=apex_positions
  UniqueApexPositionAccountCusipDayPublished apexClearingAccountId cusip dayPublished

becomes:

unique_apex_position_account_cusip_day_published

In our codebase, we use Postgresql's default naming convention for unique constraints though, which is something like:

apex_positions_apex_clearing_account_id_cusip_day_published_key

I think the formula is roughly:

tablename_col1_col2_col3_key

except in cases of overflowing the 63 character limit, which I would have to lookup the algorithm for.

So, I'm interested in adding support for Persistent to use Postgres' default naming scheme. I think this would work more nicely for codebases that use external tools to migrate Postgres, or are seeking compatibility with an existing Postgres schema.

I haven't done something like this before in Persistent, but I think what I'd want to do is:

1. Add a new field to PersistSettings to configure the unique constraint name. Probably this should be a Maybe so it can default to the old behavior
2. This field should be a function that takes a record of relevant information, that includes the Haskell table name, sql= table name, Haskell field names, sql field names, etc. (Not sure exactly how this will look but I have a rough idea), and returns the desired unique constraint name.
3. Export a function that has the type signature of that field, that implements Postgres default naming scheme.

I believe this would be a breaking change to PersistSettings as currently setup, so would have to come in a later Persistent version.

A potential alternative solution is to make constraint names optional, and let Postgres generate the names itself. I suspect this wouldn't work well with Persistent's current migration patterns though.

Start with PersistSettings in Database-Persist-Quasi and review the existing unique-constraint naming and migration behavior. Define the configuration shape and PostgreSQL naming behavior, including the 63-character limit, while preserving the current default. Done means the API is documented, the generated names are covered by tests, and compatibility implications are addressed.