Re: Extended Statistics set/restore/clear functions.

>
> Hmm. Not sure yet which one is better here, TBH. The "ok" pattern
> feels a but better to me because a Datum == 0 could also be fine in
> some cases, be they existing of future cases, so that's more flexible
> by design.
>

I went with the "ok" model wherever possible.

> When I review a patch and that I want to do a clean split, I tend to
> apply the whole, then remove the parts that can be split out, reapply,
> and then generate a diff of the previously-removed code. It's just
> easier to delete code. For this patch set, it would mean removing the
> MVC variables and related structures. It is actually not that bad
> based on how you have structured the restore function; there is no
> strong dependency between each code path treating each stxkind. This
> is just thinking of possible strategy if this whole thing cannot make
> it into the tree by the freeze deadline. Some of it may be better
> than nothing of it, and it is possible to add more parameters later
> with the right basics in place. For me, review and integration tends
> to be easier as a incremental set of small-ish steps, but I think that
> you are aware of my way of doing things :D
>

I've added about 30 tests covering various things that can go wrong with
extended stats parameter combinations, parameter contents, expression
parameter combinations.

There is one WARNING I can see that still needs coverage, but I'm at a loss
as to how to set it up. It's the extended_stats.c:1202 "could not determine
element type of expression" which should only happen if we have a datatype
that appears to be an array but actually isn't...

Also improved documentation, moved some code to import_mcv to behave like
import_expressions, etc.