get_record_stream(..., 'topological', True) in pre 2.0 formats does not preserve topological sorting across stacking boundaries

The original bug report is bug #393366

This is an extension of that bug report, which only applies to bzr formats older than 2.0 (specifically KnitVersionedFiles has this problem, but GroupCompressVersionedFiles does not.)

If you have an ancestry graph such as this (time goes down):

  A
  |\
  B C
  |/|
  D E
   \|
    F

And you have repositories laid out such that the revisions on the left are in
the base repository, and the revisions on the right are in the stacked
repository (note that C will be in base as well, because it is an ancestor of
D).

In that condition, doing:
    get_record_stream([A B C D E F], 'topological', True)
should give an ordering such as:
    A B C D E F

However, the way the code is written, it always returns all revisions from the
fallback that are not in the stacked location first, and then returns revisions
from the stacked location.

So it does something like:
 A B D, C E F

And in this case, C is returned after D, which violates the 'topological'
request.

The only code I know of that triggers this is 'annotate'. The requirements to
trigger are:

1) get_record_stream(..., 'topological', True)
2) a KnitPack repository
3) Revisions which are present in the stacked location which are also ancestors
of the revisions in the fallback.

See the new test
    bzrlib.tests.per_repository_reference.test_get_record_stream.TestGetRecordStream.test_ordered_fulltext_complex

I'm fixing the simpler to fix cases for bug #393366.