pg_uuid_t support in contrib/btree_gist

I'd like to add uuid support to contrib/btree_gist.

Proposal:

* Add `contrib/btree_gist/btree_uuid.c' with implementation based
on gbtree_ninfo type description
* Modify `contrib/btree_gist/btree_utils_num.c' to support pg_uuid_t
* Modify `contrib/btree_gist/btree_gist.h' to add gbt_t_uuid type
* Add `contrib/btree_gist/btree_gist--1.2.sql' with gist_uuid_ops
* Modify `Makefile' to build btree_uuid
* Modify `contrib/btree_gist/btree_gist.control' to set default_version to
1.2
* Regression tests
* I've probably missed something, but that's the basic idea

Question:

pg_uuid_t is an opaque type in `src/include/utils/uuid.h'. To put this type
in a struct for both a new uuidKEY and the gbtree_ninfo type description
support we need the implementation of the struct that is currently hidden
in `src/backend/utils/adt/uuid.c'.

We could get around this by using gbtree_vinfo type description for uuid,
but this is not a var type. That smells a little to me.

Is modifying `src/include/utils/uuid.h' to leak the implementation details
of pg_uuid_t in `src/backend/utils/adt/uuid.c' an option? It seems pretty
drastic to make that change just for contrib/btree_gist, but the 16-byte
char[] representation seems fairly standard to me.

I don't know why this would be needed at some point in the future, but
another possible impl could be a hi/lo int64 to represent the uuid type
(like java), so leaking the implementation details would potentially add a
btree_gist dependency to ever doing this in the future.

A third option is to have our own impl of pg_uuid_t or something similar in
btree_gist. Having two independent implementations of pg_uuid_t in postgres
and btree_gist smells even worse and opens us up to dependency issues (that
may very well be caught by the regression tests).

The answer is not obvious to me how to proceed on this.

(I'm a first-time poster so please correct any procedures or etiquette I'm
missing)