SPI refactoring

Hackers,

As discussed with Tom in [1] and again with Pavel and Alvaro in [2],
here is a partial WIP refactoring of the SPI interface. The goal is to
remove as many of the SPI_ERROR_xxx codes as possible from the
interface, replacing them with elog(ERROR), without removing the ability
of callers to check meaningful return codes and make their own decisions
about what to do next. The crucial point here is that many of the error
codes in SPI are "can't happen" or "you made a programmatic mistake"
type errors that don't require run time remediation, but rather require
fixing the C code and recompiling. Those seem better handled as an
elog(ERROR) to avoid the need for tests against such error codes
sprinkled throughout the system.

One upshot of the refactoring is that some of the SPI functions that
previously returned an error code can be changed to return void. Tom
suggested a nice way to use macros to provide backward compatibility
with older third-party software, and I used his suggestion.

I need guidance with SPI_ERROR_ARGUMENT because it is used by functions
that don't return an integer error code, but rather return a SPIPlanPtr,
such as SPI_prepare. Those functions return NULL and set a global
variable named SPI_result to the error code. I'd be happy to just
convert this to throwing an error, too, but it is a greater API break
than anything implemented in the attached patches so far. How do others
feel about it?

If more places like this can be converted to use elog(ERROR), it may be
possible to convert more functions to return void.

[1] https://www.postgresql.org/message-id/13404.1558558354%40sss.pgh.pa.us

[2]
https://www.postgresql.org/message-id/20191106151112.GA12251%40alvherre.pgsql
--
Mark Dilger