Implement visual-specific bindings such as `d`, `c`, `y`, and `~`

[jparoz]

The idea

While playing around with an implementation of #50, I found myself surprised by the behaviour of some commands in visual mode. Specifically, I expected vljd to behave the same as vljx, and Vjd to behave (basically) the same as dddd. Currently there seems to be no change in commands based on whether or not we're in visual mode. This seems to be reflected in content_scripts/commands.js having no "visual" section.

Vim's :h visual-operators lists these visual-specific bindings:

4. Operating on the Visual area				*visual-operators*

The operators that can be used are:
	~	switch case					|v_~|
	d	delete						|v_d|
	c	change (4)					|v_c|
	y	yank						|v_y|
	>	shift right (4)					|v_>|
	<	shift left (4)					|v_<|
	!	filter through external command (1)		|v_!|
	=	filter through 'equalprg' option command (1)	|v_=|
	gq	format lines to 'textwidth' length (1)		|v_gq|

Of these, to me the only ones that make any sense to be implemented in sheetkeys are ~, d, c, and y. All of them should be fairly easy to implement. The vim docs also mention (below the above-quoted section) that many normal-mode commands work in visual-mode, and specifies how they behave in terms of linewise/cellwise/etc. behaviour. In sheetkeys, I think it should be sufficient for visual-mode mappings to fall back to normal-mode mappings, if there is no visual-specific mapping for a given keystring.

@philc, if you think this kind of change would be acceptable, I'd like to implement it.

Questions

• Should these visual bindings be accessible to the user? Currently insert-mode bindings are not user-specifiable. Possibly both insert- and visual-specific bindings could be exposed as part of a settings UI, discussed in #38.
• Should visual-mode bindings override normal-mode bindings (and similar for insert-mode bindings)? Currently insert-mode bindings are overridden by normal-mode bindings; I suspect this is a hedge against users being unable to reconfigure something particular they need, and so it might be fine to switch this if we make mode-specific bindings user-mappable (as per the above).