Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

Hello,

When an empty namespace is being initially populated with certain objects,
it is possible for a DROP SCHEMA operation to come in and delete the
namespace without using CASCADE. These objects would be created but are
left unusable. This is capable of leaving behind pg_class, pg_type, and
other such entries with invalid namespace values that need to be manually
removed by the user. To prevent this from happening, we should take an
AccessShareLock on the namespace of which the type, function, etc. is being
added to.

Attached is a patch that covers the following CREATE commands:
CREATE TYPE, CREATE FUNCTION, CREATE AGGREGATE, CREATE OPERATOR FAMILY,
CREATE OPERATOR CLASS, and CREATE OPERATOR

Example Reproduction
Session1: CREATE SCHEMA testschema;
Session1: BEGIN;
Session1: CREATE TYPE testschema.testtype;
Session2: DROP SCHEMA testschema;
Session1: COMMIT;
// The DROP SCHEMA schema succeeds in session 2 and session 1's COMMIT goes
through without error but the pg_type entry will still be there for typname
testtype. This example is for just a simple TYPE object but the other
objects can be reproduced the same way in place of CREATE TYPE.

Related Postgres 9.2 commit (note in commit message that "We need similar
protection for all other object types"):
https://github.com/postgres/postgres/commit/1575fbcb795fc331f46588b4520c4bca7e854d5c

The patch itself is relatively trivial by just adding copy/paste lock
acquires near other lock acquires. I wasn't sure if this needed a decently
sized refactor such as the referenced commit above.

Regards,
Jimmy