Simplifying how nbtree represents array scan keys

nbtree preprocessing simplifies/normalizes the representation of SAOP
style inequalities by replacing the array with a simple scalar
sk_argument value -- the extremal element. For example, the following
query normalizes to a non-SAOP representation:

select * from tenk1 where ten < any('{3, 4, 5}');

That is, preprocessing outputs the same scan keys it would output if
the query had been written this way instead:

select * from tenk1_dyn_saop where ten < 5;

However, preprocessing will *not* remove/exclude the SK_SEARCHARRAY
marking from the output scan key on "ten". That makes it necessary for
code in places like _bt_advance_array_keys to deal with
SK_SEARCHARRAY-marked scan keys that don't actually have an array
associated with them (i.e. that aren't = strategy scan keys, which
must have a real array when they survive preprocessing). This is
confusing, and somewhat bug-prone; it's easy to forget that this
inequality special case exists.

Attached patch cleans things up in this area by teaching preprocessing
to unset the SK_SEARCHARRAY flag on an inequality whose array is to be
normalized-away (i.e. any SAOP inequality that can appear in the
output scan key array/be used by the scan). This allows
_bt_advance_array_keys and _bt_check_compare to stop testing
"sk_strategy == BTEqualStrategyNumber" when they see that
SK_SEARCHARRAY is set within the key's sk_flags.

This patch is only intended as refactoring, but it fixes a tiny
buglet: the _bt_advance_array_keys's "perform a precheck of the least
significant key" optimization will now work as expected when the least
significant key happens to be a SAOP inequality scan key (actually I
should say a key that *was* a SAOP inequality on input into
preprocessing). It's not hard to imagine other issues like that
slipping in in the future, so tightening things up seems like a good
idea.

--
Peter Geoghegan