Fix transaction bug in PostgreSQLAdapter#disable_referential_integrity

PostgreSQL requires explicitly rolling back to a pre-existing
savepoint in order to resume execution after a failed statement
within a transaction.  The existing code would fail when executed
within a transaction without superuser privs since these requirements
weren't being met.  Since normal testing is done with superuser privs,
the rescue clauses in PostgreSQLAdapter#disable_referential_integrity
weren't actually being tested, leading to false confidence in the
code.

The test/cases/adapters/postgresql/referential_integrity_test.rb
test suite was created to do much more extensive testing on the
PostgreSQL-specific implementation.  It tests a wide variety of
scenarios and corner conditions.  It includes a standard set of pre-
and post-conditions to validate around each test.  It regrettably uses
some slightly kludgy approaches to handle the following:
* Testing without superuser privs.  In order to do this, it creates
  a temporary role to hold superuser privs and then relinquishes
  superuser privs for the current user before carrying out the actual
  test and then uses that temporary role to regain superuser privs.
* Testing without an enclosing transaction.  These tests have to
  operate without transactional fixtures, and as a result must clean
  the tables in the teardown.  These tests are isolated in the
  PostgresqlReferentialIntegrityTestWithoutTransactionalFixtures
  class.
* Validating that savepoint names are not reused in a nested manner.
  This ensures that a new savepoint can be created with a savepoint
  name that was used previously only if the previous savepoint has
  been released.  This is done by stubbing the create_savepoint and
  release_savepoint methods for PostgreSQLAdapter and having the new
  stubs keep track of savepoint creation and releases.

The changes to PostgreSQLAdapter#disable_referential_integrity are
intended to address the following issues:
* Ensure that disable_referential_integrity successfully operates
  both within and outside of an enclosing transaction, both with
  respect to failing SQL statements issued by the code as well as
  those issued by the passed block.
* Ensure that disable_referential_integrity behaves in a logical
  manner in nested calls.  The existing code would restore referential
  integrity when the innermost call returned, rather than in the
  outermost call.
* Take advantage of the new named savepoint support in ActiveRecord.
* Ensure that named savepoints were not nested.  Nested creation of
  savepoints is supported by PostgreSQL, but this is a violation of
  the ANSI standard and can lead to difficult to understand bugs.

No attempt was made in this update to handle deferring referential
integrity constraints when operating without superuser privs.  That
remains an issue, but will be addressed in a future update.