log: clean-up log conflict search

[pav-kv]

This PR cleans up raftLog.maybeAppend and raftLog.findConflict functions, now that they accept the new logSlice type as input. This replaces a bunch of ad-hoc arithmetics on the raw entries slice with a more understandable "fast-forward" logic on a logSlice.

This also removes a redundant panic in maybeAppend. An equivalent panic is present in the raftLog.append method which is triggered under the same conditions. This panic behaviour is tested in TestLogMaybeAppend, and hasn't changed.

Related to #144

[pav-kv]

@ahrtr This PR is based on top of testing clean-ups in #151 and #147. Only the last 3 commits need to be reviewed as part of this PR. Feel free to also expedite finishing the blocking PRs. Thank you.

[pav-kv]

CC @nvanbenschoten

Specifically, consider the TODOs I've added in findConflict method. I wonder if this would give any significant boost to log append performance. Currently, we (re-)scan the log upon every append request. I suppose though the win wouldn't be large, because the common/happy path is that the append is right at the tip of the log. But in the unhappy path we can save quite a bit of scanning (and the unhappy path is when the cluster is struggling, so savings can help it recover quicker / not add additional resource pressure).