Saving stack space in nbtree's _bt_first function

nbtree's _bt_first function uses arrays on the stack to store the scan
keys that will be used for initial positioning purposes. We could use
dynamic allocation here instead, but experience has shown that that
would cause performance issues -- particularly during nestloop joins
with an inner index scan. The amount of stack space used by _bt_first
does still seem kind of excessive, though.

Perhaps most notably, "BTScanInsertData inskey" takes up 2328 bytes.
There isn't much we can do about that, unless we're willing to make
_bt_first more complicated. The "inskey" variable is so large because
it ends with an array of INDEX_MAX_KEYS-many (generally 32)
ScanKeyData structs -- these structs are themselves fairly large
struct (they're 72 bytes each).

However, there's no reason why "ScanKeyData
notnullkeys[INDEX_MAX_KEYS]" needs to be an array at all. In practice,
_bt_first will only need a single temp notnullkeys ScanKeyData, since
there can never be more than a single deduced NOT NULL constraint used
within our final insertion scan key.

Attached patch shows how this could work. It saves us a little over 2
KiB of stack space, which seems worthwhile given that the patch is so
simple.

I'll submit this patch to the next open commitfest for Postgres 19.

--
Peter Geoghegan