gencgc: Fix commentary for page table allocation field.

  * The commentary for the page table allocation field was
misleading, presumably not updated when the definitions for the
constants used for its actual contents were last changed, and cost
me a bit of surprise and time spent trying to figure out why core
file saving and loading worked at all.

  * Updated the commentary on the allocation field to match
current reality, and added cross-references between the field
itself and the definitions for its contents, so that a future
desync between commentary and reality is less likely.
gencgc: Defer moving pinned pages to newspace as late as possible.

  * Rather than moving pinned pages to newspace immediately, defer
moving them until just before we start to scavenge (evacuate) all
of the oldpsace pages.

  * This, in theory, makes it easier to move pages to newspace if
they are mostly-live, rather than having to allocate new pages for
the data (increasing peak address-space use during GC), assuming
that we know that some page meets such criteria.

  * While we're here, commentary updates also replace an "XX I'd
rather not do this but the GC logic can't cope with not doing it"
with an actual explanation of WHY it needs to be done.  In fact,
commentary updates explain it twice, in two different locations.
gencgc: Commentary fix for struct page, field region_start_offset.

  * Simply describing region_start_offset as being related to an
allocation region which contains a page is disingenuous at best,
and misleading at worst.  Its relation with an alloc_region is due
to its initialization strategy, and has nothing to do with what
the value is for.

  * Say it like it is, it's an offset to a known object boundary,
from where we can start a call to gc_search_space() or scavenge().
That's what it's for, not for keeping track of alloc_regions.
gencgc: Rename page_table field region_start_offset to scan_start_offset.

  * Let's call it what it is: The offset from where to start any
scan through the page to the start of the page.  The only relation
this field has to an alloc_region is the way it is initialized.
gencgc: Introduce a new predicate, page_starts_contiguous_block_p().

  * There are a number of places in gencgc where scan_start_offset
for a page is tested for zero.  Invariably, this is actually
testing to see if a page starts a contiguous block...  Or starts
on an object boundary.

  * Extract the various tests for a zero scan_start_offset to a
new inlined predicate function, page_starts_contiguous_block_p(),
thus revealing the intent of what's going on far better than the
bare test.
gencgc: Introduce a new predicate, page_ends_contiguous_block_p().

  * There are a number of places in gencgc where a number of
attributes of a page and possibly the subsequent page are tested
for various values.  Invariably, this is actually testing to see
if a page ends a contiguous block.

  * Extract the various tests to a new inlined predicate function,
page_ends_contiguous_block_p(), thus revealing the intent of
what's going on far better than the bare tests, and coalescing the
code to a single copy to make it easier to fix if there is a bug
in it (and there is, but this is a refactoring commit, not a
behavior change commit).
gencgc: Fix potential out-of-bounds access in page_ends_contiguous_block_p().

  * If we're testing to see if the LAST page in dynamic space is
the end of a contiguous block, and it is a full page (bytes_used
is GENCGC_CARD_BYTES), we turn around and start investigating the
next page table entry... but there isn't one, it's beyond the end
of the allocation.

  * Fix, by bounds-testing the page index against the index of the
high-water mark for dynamic space.  This is guaranteed to be no
more than the total maximum for the page table, and is slightly
more micro-efficient than using the actual maximum, as any page
after the high-water mark will be page_free_p().
gencgc: Decide earlier about pinning large object pages.

  * The old logic here called maybe_adjust_large_object(), and
then re-checked the pointer to preserve for validity.  This is
non-optimal, as it means that maybe_adjust_large_object can't
promote pages to newspace directly, it instead merely adjusts the
page allocation to fit the possibly-shrunken object.

  * It turns out that large_object pages can contain bignums,
vectors, code-objects, or in unusual cases instances.  Neither
bignums, vectors, nor instances can contain embedded objects.
Code-objects can contain only functions or LRAs.  None of these
objects have list-pointer-lowtag on their references.  The "tail"
of a shrunken object is comprised of conses with both cells as
fixnum zero.  The minor catch is that we allow untagged pointers
to pin code-allocated pages, but the saving grace here is that
code-objects don't shrink.

  * Alter preserve_pointer() to test the lowtag and page type to
check for invalid pointers to large-object pages before calling
maybe_adjust_large_object() instead of bounds-checking the pointer
after the fact.
room: Fix reconstituting CONS cells with unbound-marker in the CAR.

  * When I originally rewrote ROOM in terms of RECONSTITUTE-OBJECT,
I looked at what constitutes a valid CONS according to the runtime.
I noticed that one of the immediate types was an unbound marker
and said to myself "nobody's going to put one of those in a list".
This turned out to be a mistake.

  * x86 systems (and plausibly not any others) put unbound-markers
in lists when loading FASLs.  I have no real idea how or why, but
they do.  This would lead to an error, "Unrecognized widetag #x4A
in reconstitute-object".

  * Fix, by recording unbound-marker-widetag as being valid as the
first word of a CONS cell.

  * Issue reported by "scymtym" on #sbcl.