Visual downwards move with big count goes to end of line and new configuration options

[saulaxel]

The lose of one column issue with 'virtualedit' wasn't related with the
longest line as previously thought, but with the first line (smallest
one) of selection, so changing it fixes now for real (hopefully) the bug
of losing one column after moving.

Using "range" in functions that didn't used visual selection was a
problem when (a:firstline + count) greater than the last line so that
range was deleted and replaced with at the function calls.

The name 'are_same_line' was really referring to a column, so it was
renamed after 'are_same_cols'

Create function to initialize configurations variables to its defaults.

The variable g:move_map_key can also be a dictionary to permit
enabling/disabling of parts of the default mappings using the entries
'vertical' and 'horizontal' and its subentries 'normal' and 'visual'.

[matze]

I still lost the first column and since I enabled listchars I see another issue: in visual blocks with multiple lines and different line lengths, trailing spaces are inserted when shifting left and right.

[matze]

Someone seems to write a lot of Python code as well ;-)

[saulaxel]

I still don't find a way to avoid inserting trailing spaces after a left/right move. But found that just removing the spaces after those operations is a possible solution. It is not exactly the same as not inserting them, because removing after an operation can also delete existing (possible wanted) spaces but this solution still will do right most times and could be configurable for those who don't want it.