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