PhysicalWritableLogChannel reports correct positions

A recent change b549c380817e5be0159698f57743ae10331a6568 changed
transaction appending logic to batch writes to the underlying
StoreChannel, instead of for every append. On slaves in HA which now
applies transactions in batches didn't see any change in log position
until a whole batch had been applied. This had an unexpected effect that
potentially many transactions would be appended with the same position in
its log start entry.

The only actual fix in this commit is that
PhysicalWritableLogChannel#getCurrentPosition() now looks at the
underlying channel AND the buffered data that hasn't been written yet.
Merge pull request #3326 from tinwelint/2.2-fix-log-position

PhysicalWritableLogChannel reports correct positions