parse/analyze API refactoring

I have found some of the parse/analyze API calls confusing one too many 
times, so here I'm proposing some renaming and refactoring.

Notionally, there are three parallel ways to call the parse/analyze 
phase: with fixed parameters (for example, used by SPI), with variable 
parameters (for example, used by PREPARE), and with a parser callback 
(for example, used to parse the body of SQL functions).  Some of the 
involved functions were confusingly named and made this API structure 
more confusing.

For example, at the top level there are pg_analyze_and_rewrite() and 
pg_analyze_and_rewrite_params().  You'd think the first one doesn't take 
parameters and the second one takes parameters.  But the truth is, the 
first one takes fixed parameters and the second one takes a parser 
callback.  The parser callback can be used to parse parameters, but also 
other things.  There isn't any variant that takes variable parameters; 
that code is sprinkled around other places altogether.

One level below that, there is parse_analyze() (for fixed parameters) 
and parse_analyze_varparams() (good name).  But there is no analogous 
function for the callback variant; that code is spread out in 
pg_analyze_and_rewrite_params().

And then there are parse_fixed_parameters() and 
parse_variable_parameters().  But they don't do any parsing at all. 
They just set up callbacks for the parsing to follow.

This doesn't need to be so confusing.  With the attached patch set, the 
calls end up:

pg_analyze_and_rewrite_fixedparams()
   -> parse_analyze_fixedparams()
        -> setup_parse_fixed_parameters()

pg_analyze_and_rewrite_varparams() [new]
   -> parse_analyze_varparams()
        -> setup_parse_variable_parameters()

pg_analyze_and_rewrite_withcb()
   -> parse_analyze_withcb() [new]
        -> (nothing needed here)

(The "withcb" naming maybe isn't great; better ideas welcome.)

Not included in this patch set, but food for further thought:  The 
pg_analyze_and_rewrite_*() functions aren't all that useful (anymore). 
One might as well write

     pg_rewrite_query(parse_analyze_xxx(...))

The only things that pg_analyze_and_rewrite_*() do in addition to that 
is handle log_parser_stats, which could be moved into parse_analyze_*(), 
and TRACE_POSTGRESQL_QUERY_REWRITE_*(), which IMO doesn't make sense to 
begin with and should be in pg_rewrite_query().