Further hacking on SPITupleTable struct

Thinking more about the public/private field distinction we just
specified --- it's always annoyed me that SPITupleTable doesn't
provide a number-of-valid-rows field, so that callers have to
look at the entirely separate SPI_processed variable in order
to make sense of SPI_tuptable. I looked a bit more closely at
the code in question, and realized that it was just Randomly
Doing Things Differently from every other implementation we have
of expansible arrays. Not only is it randomly different, but
it's not even better than our usual method of tracking current
and maximum numbers of elements: it has to do extra subtractions.

Accordingly, I propose the attached follow-on to fec0778c8,
which replaces the "free" field with a "numvals" field that
is considered public.

I poked around for callers that might prefer to use SPI_tuptable->numvals
in place of SPI_processed, and didn't immediately find anything where the
benefit of changing seemed compelling. In principle, though, it should
be possible to simplify some callers by needing only one variable to be
passed around instead of two.

Thoughts?

regards, tom lane