Two minor bugs in GIN fast insertion WAL-logging

(more fruit from my little page-image-comparison hack)

WAL replay of filling a GIN fast list page is a bit funky. I believe
there are two bugs in it, but they're both harmless:

writeListPage function initializes the page, and adds a bunch of tuples
to it. All the tuples are included in the WAL record, and marked as
belonging to the buffer. So far so good. But since the page is
re-initialized from scratch, its LSN is always 0, so XLogInsert will
always create a full-page-image of it. That's harmless, but usually we
don't do a full-page image when we have all the information to re-create
the page from scratch anyway. It does cause some unnecessary bloating of
the WAL, because the information to recreate the page from scratch takes
less space than the full page image.

The second bug is in the redo routine of that, ginRedoInsertListPage.
The loop that inserts all the tuples to the page is missing an "off++",
so it inserts all the tuples to offset 1. So the tuples end up on the
page in reverse order. Not just reverse physical order, like in the
B-tree split code, but reverse itemno order. That happens to work
because the order of the tuples doesn't matter to scans, and we also
never remove individual tuples from fast list pages. You only see this
happening if you run with full_page_images=off, because of the first bug.

Although these are harmless, the second bug in particular is a bit
scary. I think we should fix and backpatch these.

- Heikki