[PATCH][PROPOSAL] Add enum releation option type

Hi!
While working with my big reloption patch, 
https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m
I found out, that all relation options of string type in current postgres, are 
actually behaving as "enum" type. But each time this behavior is implemented 
as validate function plus strcmp to compare option value against one of the 
possible values.

I think it is not the best practice. It is better to have enum type where it 
is technically enum, and keep sting type for further usage (for example for 
some kind of index patterns or something like this).

Now strcmp in this case does not really slow down postgres, as both string 
options are checked when index is created. One check there will not really 
slow down. But if in future somebody would want to have such option checked on 
regular basis, it is better to have it as enum type: once "strcmp" it while 
parsing, and then just "==" when one need to check option value in runtime.

The patch is in attachment. I hope the code is quite clear.

Possible flaws:

1. I've changed error message from 'Valid values are "XXX", "YYY" and "ZZZ".'  
to 'Valid values are "XXX", "YYY", "ZZZ".' to make a code a bit simpler. If it 
is not acceptable, please let me know, I will add "and" to the string.

2. Also about the string with the list of acceptable values: the code that 
creates this string is inside parse_one_reloption function now. It is a bit 
too complex. May be there is already exists some helper function that creates 
a string "XXX", "YYY", "ZZZ" from the list of XXX YYY ZZZ values, I do not 
know of? Or may be it is reason to create such a function. If so where to 
create it? Inside "reloptions.c"? Or it can be reused and I'd better put it 
somewhere else?

I hope there would be not further difficulties with this patch. Hope it can be 
committed in proper time.

-- 
Do code for fun.