Test case exposing bug #842695.

When restricting a log to a given directory, _generate_deltas will be sued
to find out matching revisions.  It does so using
repository.get_deltas_for_revisions, which describes the difference that the
given revision introduced with respect to its left hand parent.  So files
introduced by the right hand parent of a commit will be considered "added"
by the delta.  This can lead to false positives, to commits reportedly
touching a given dir although they only merged stuff introducing these
files.

Note that for in some cases, this is expected behaviour: every merge on the
route from a modification to its first merge into mainline should be
considered touched by that modification.  But for stuff already included in
main line, those modifications should not be reported again if they are
merged into some side line.  In other words, every change should have one
direct child reporting it, but no more.

_generate_deltas apparently processes revisions in batches of 200.  After
each batch, the found additions are removed from the fileid_set and won't be
tracked in the next batch.  Processing terminates if there are no more files
to track.  Due to this logic, a false positive in one batch can lead to
false negatives later on, as the file gets removed too early, and its actual
addition is therefore lost.