Fix assorted fallout from IS [NOT] NULL patch.

 Fix assorted fallout from IS [NOT] NULL patch.
 
 Commits 4452000f3 et al established semantics for NullTest.argisrow that
 are a bit different from its initial conception: rather than being merely
 a cache of whether we've determined the input to have composite type,
 the flag now has the further meaning that we should apply field-by-field
 testing as per the standard's definition of IS [NOT] NULL.  If argisrow
 is false and yet the input has composite type, the construct instead has
 the semantics of IS [NOT] DISTINCT FROM NULL.  Update the comments in
 primnodes.h to clarify this, and fix ruleutils.c and deparse.c to print
 such cases correctly.  In the case of ruleutils.c, this merely results in
 cosmetic changes in EXPLAIN output, since the case can't currently arise
 in stored rules.  However, it represents a live bug for deparse.c, which
 would formerly have sent a remote query that had semantics different
 from the local behavior.  (From the user's standpoint, this means that
 testing a remote nested-composite column for null-ness could have had
 unexpected recursive behavior much like that fixed in 4452000f3.)
 
 In a related but somewhat independent fix, make plancat.c set argisrow
 to false in all NullTest expressions constructed to represent "attnotnull"
 constructs.  Since attnotnull is actually enforced as a simple null-value
 check, this is a more accurate representation of the semantics; we were
 previously overpromising what it meant for composite columns, which might
 possibly lead to incorrect planner optimizations.  (It seems that what the
 SQL spec expects a NOT NULL constraint to mean is an IS NOT NULL test, so
 arguably we are violating the spec and should fix attnotnull to do the
 other thing.  If we ever do, this part should get reverted.)
 
 Back-patch, same as the previous commit.
 
 Discussion: <10682.1469566308@sss.pgh.pa.us>