fsck.gfs2: take hash table start boundaries into account
    
    When checking the hash table in pass2, we can't just keep doubling
    the length for each consecutive check because the number of pointer
    copies (aka length) is also tied to the starting offset. If the
    starting offset is invalid for the length, it might treat a chunk of
    the hash table as bigger than it should, eventually overwriting good
    entries. Along the same lines, while we're trying to determine the
    length, it's not good enough to double the length and check if the
    hash table entry matches. The reason is: there can be several values
    overwritten with the same value, 0x00, that indicates places where
    pass1 found an invalid leaf block pointer. To avoid that, we need to
    check intermediate values as well, and stop if we find a gap.
    
    rhbz#902920