Dropping a foreign key constraint or a table that owns an FK currently
blocks reads on the referenced table due to AccessExclusiveLock taken while
removing the FK's internal RI triggers and constraint metadata.  In busy
systems, this brief full-read outage can cause user-visible timeouts for
otherwise read-only traffic.
This change narrows the lock reduction to the safe scope, retaining
AccessExclusiveLock on the table that owns the constraint and reducing
locks only on the referenced table's RI action-trigger removal:
1. RemoveTriggerById(): use ShareRowExclusiveLock only for internal RI
   action triggers on the referenced table; all other triggers remain
   at AccessExclusiveLock.
2. dropconstraint_internal(): when dropping an FK, open the referenced
   table with ShareRowExclusiveLock to match trigger deletion and allow
   concurrent reads.
The table being dropped or directly altered (the constraint-owning table)
continues to acquire AccessExclusiveLock as before. Only the referenced
tables of foreign keys see the reduced lock level.
Examples of affected operations:
- ALTER TABLE fktable DROP CONSTRAINT: AccessExclusive on fktable (unchanged),
  ShareRowExclusive on the referenced pktable, allowing SELECTs on pktable.
- DROP TABLE fktable: AccessExclusive on fktable (unchanged), and
  ShareRowExclusive on the referenced pktable while removing RI action triggers.
- Self-referential FKs: the altered table still takes AccessExclusive, so
  SELECTs on that table block (unchanged).
Correctness is preserved because:
- Writers are serialized: ShareRowExclusive conflicts with RowExclusiveLock
  and stronger, so no DML can race RI trigger removal.
- Relcache invalidation at commit ensures metadata changes become visible
  to subsequent queries.
- Prepared plans continue to work; plans depending on the owning table's
  constraints remain protected by AccessExclusive on that table.
Updated isolation tests:
- fk-drop-constraint-concurrency: new permutation asserting a SELECT cursor
  on the referencing table blocks the FK drop (owning table remains at
  AccessExclusive); also covers regular FKs, DROP TABLE of the FK table,
  self-referential FKs, and relcache invalidation.