journal: make next_with_matches() always use f->current_offset

journal: make next_with_matches() always use f->current_offset

next_with_matches() is odd in that its "unit64_t *offset" parameter is
both input and output. In other it's purely for output.

The function is called from two places in next_beyond_location(). In
both of them "&cp" is used as the argument and in both cases cp is
guaranteed to equal f->current_offset.

Let's just have next_with_matches() ignore "*offset" on input and
operate with f->current_offset.

I did not investigate why it is, but it makes my usual benchmark run
reproducibly faster:

$ time ./journalctl --since=2014-06-01 --until=2014-07-01 > /dev/null

real    0m4.032s
user    0m3.896s
sys     0m0.135s

(Compare to preceding commit, where real was 4.4s.)