Fix to enum hashing for dump and restore

Hello,

I have discovered a bug in one usage of enums. If a table with hash
partitions uses an enum as a partitioning key, it can no longer be
backed up and restored correctly. This is because enums are represented
simply as oids, and the hash function for enums hashes that oid to
determine partition distribution. Given the way oids are assigned, any
dump+restore of a database with such a table may fail with the error
"ERROR: new row for relation "TABLENAME" violates partition constraint".

This can be reproduced with the following steps:
************************************************
create database test;
\c test
create type colors as enum ('red', 'green', 'blue', 'yellow');
create table part (color colors) partition by hash(color);

create table prt_0 partition of part for values 
with (modulus 3, remainder 0);

create table prt_1 partition of part for values 
with (modulus 3, remainder 1);

create table prt_2 partition of part for values 
with (modulus 3, remainder 2);
insert into part values ('red');

/usr/local/pgsql/bin/pg_dump -d test -f /tmp/dump.sql
/usr/local/pgsql/bin/createdb test2
/usr/local/pgsql/bin/psql test2 -f /tmp/dump.sql
************************************************

I have written a patch to fix this bug (attached), by instead having the
hashenum functions look up the enumsortorder ID of the value being
hashed. These are deterministic across databases, and so allow for
stable dump and restore. This admittedly comes at the performance cost
of doing a catalog lookup, but there is precedent for this in
e.g. hashrange and hashtext.

I look forward to your feedback on this, thank you!

Sincerely,
Andrew J Repp (VMware)