Re: Fully documenting the design of nbtree row comparison scan keys

I didn't understand every nuance of row compare inequalities myself
until quite recently. The rules with NULLs are particularly tricky.

It seems worthwhile to clear things up now in large part due to the
recent addition of code in places like _bt_advance_array_keys -- code
that wants to to treat row compare keys as if they were just a simple
scalar inequality on the row compare's most significant column. That
general behavior isn't new (e.g., _bt_first has long ignored row
compare scan key markings when deducing a NOT NULL constraint), but
it's not easy to see why it's correct.