Fix '}'(MoveParagraphEnd) behaviour to accurately emulate Vim's

[cvaldev]

What this PR does / why we need it:
This PR makes it so MoveParagraphEnd behaves exactly like it does in Vim when it is executed with an operator. It doesn't change the behaviour without an operator, which is already accurate.

The current implementation doesn't respect the cursor position, breaks when it is repeated by an operator with a count (only moves a paragraph on an odd number iteration) and doesn't respect the blank line at the end of a paragraph like regular Vim.

I've added two properties to MoveParagraphEnd:

1. iteration: Keeps track of the iteration, this way we know when we're on the last iteration, in which case we want to return the position just before the blank line that paragraphEnd represents, so that we accurately emulate Vim's behaviour.

2. isFirstLineWise: Will be true if the command was initiated at the beginning of line. We need this because the } motion will be repeated count number of times and each time we'll receive the position of the previous paragraphEnd which is the blank line after the EoL of the last line in the paragraph. As you may have noticed, that position would always be at the beginning of the line and not be an accurate representation of where the command was initiated.

Which issue(s) this PR fixes
Fixes #4488

The issue was being caused by isLineWise being true, thus resulting in paragraphEnd.getLeftThroughLineBreaks being returned which when we received it as a position on a subsequent iteration of the } motion meant we were still on the same paragraph, that's why the counts were paired ([1,2] =1, [3,4]=2. [5,6] =3, etc..) and it would only move a paragraph on odd numbers.

Special notes for your reviewer:
Any feedback is welcomed and appreciated.