generic reloptions improvement

Hi,

Here's a patch for improving the general reloptions mechanism. What
this patch does is add a table-based option parser. This allows adding
new options very easily, and stops the business of having to pass the
minimum and default fillfactor each time you want the reloptions
processed. (This approach would not scale very well; each new reloption
requires more parameters to default_reloptions, and at the same time we
are forcing external AMs to support fillfactor, which they may very well
do not. For example GIN was already passing useless values
pointlessly.)

I kept StdRdOptions as a fixed struct, which fixes the previous complain
about speed. The new code parses the array and stores the values into
the fixed struct. The only new thing in this area is that
default_reloptions has to walk the returned array of relopt_gen to store
the values in the struct. So in order to add a new option, it is
necessary to patch both the options table (intRelOpts, etc) *and*
default_reloptions. This is a bit ugly but it's the only way I found to
keep both generality and speed.

Right now, external AMs cannot do anything much apart from fillfactor,
but it is very simple to add a routine to register a new "reloption
kind" and another to register options in the table. That and a new
*_reloptions routine (which needs to be registered in pg_am) would allow
an AM to create whatever options it needs.

Note that the only types supported are int, bool, real. We don't
support strings. I don't see this as a problem, but shout if you
disagree. (In the current patch, the bool and real lists are empty.
The autovacuum patch adds items to both.)

The patch to add the autovacuum options on top of this is very light on
reloptions.c but heavy on lots of other places, which is why I'm
submitting this separately.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.