SelectionMover.countStepsToPosition will always round both the cursor and target to previous accepted position

Previous implementation would result in some unexpected behaviours when
both the cursor and the requested position were in locations not considered
valid by the supplied filter. This would cause the number of steps between
these to fluctuate unexpectedly by 1.

This change fixed the local user cursor advancement logic (odtDocument, ln 359)
so that the current user's cursor will now acurrately report it's position.
For the failing operation test, previously getCursorPosition was returning
one too many (6 rather than 5), preventing the cursor migration logic from
activating. Now, this logic incorrectly advances the cursor and attached text
node passed the annotation end in the now-failing test.