Rework confusing permissions for LOCK TABLE

The existing permissions for LOCK TABLE are surprising/confusing. For
instance, if you have UPDATE privileges on a table, you can lock in any
mode *except* ACCESS SHARE.

  drop table x cascade;
  drop user u1;
  create user u1;
  create table x(i int);
  grant update on x to u1;

  set session authorization u1;
  begin;
  lock table x in access exclusive mode; -- succeeds
  commit;
  begin;
  lock table x in share mode; -- succeeds
  commit;
  begin;
  lock table x in access share mode; -- fails
  commit;

I can't think of any reason for this behavior, and I didn't find an
obvious answer in the last commits to touch that (2ad36c4e44,
fa2642438f).

Patch attached to simplify it. It uses the philosophy that, if you have
permissions to lock at a given mode, you should be able to lock at
strictly less-conflicting modes as well.


-- 
Jeff Davis
PostgreSQL Contributor Team - AWS