journal: optimize iteration by returning previously found candidate entry

In next_beyond_location() when the JournalFile's location type is
LOCATION_SEEK, it means there's nothing to do, because we already have
the location of the candidate entry. Do an early return. Note that now
next_beyond_location() does not anymore guarantee on return that the
entry is mapped, but previous patches made sure the caller does not
care.

This optimization is at least as good as "journal: optimize iteration:
skip files that cannot improve current candidate entry" was.

Timing results on my workstation, using:
$ time ./journalctl -q --since=2014-06-01 --until=2014-07-01 > /dev/null

Before "Revert "journal: optimize iteration: skip files that cannot
improve current candidate entry":

real    0m5.349s
user    0m5.166s
sys     0m0.181s

Now:

real    0m3.901s
user    0m3.724s
sys     0m0.176s

0 files changed, 0 insertions, 0 deletions