The interesting part of the layout of page 2 is:

- frame #40 is a section frame with a text frame which is in a list
  ("A")
- frame #48 is a section frame after that, with the same top=19213

Given that frame #40 has height > 0, they overlap when the page is
rendered. What happens is:

- frame #40 grows
- there are other section frames between #40 and #48 in-between, but
  they don't have an SwSection
- these frames are skipped
- then the position of #48 is invalidated

So the next time we calculate the position of #48, we look the last
skipped (previous) section frame (which still has top=19213, since its
position was not invalidated above), and since its height is 0, we
conclude that our current top=19213 is valid after all.

This is like this since commit 84a3db80
(initial import, 2000-09-18), so leave the code there that invalidates
not only the next frame, but all the way down to the first
non-SwSection-less-SwSectionFrame. But instead of just invalidating the
last frame, invalidate the in-between SwSection-less-SwSectionFrames as
well.

In practice this did not cause a problem in case the document has no
layout cache. If it does, then the frames are created on pages hinted by
the cache, then later moved to their final place. In practice this bug
was visible only in this later case. (I.e. such a layout cache can be
only created if the machine that saved the document last time does not
have the fonts needed by the document installed; and then the document
is opened on an other machine which has those fonts.)

Change-Id: I02ae9f63d0b4b5e9d014df53ed2cf21a04b15090
Reviewed-on: https://gerrit.libreoffice.org/60502Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins