Adds support for:
  - api:vim_input("<D-a>")
  - ":nnoremap <C-D-S-...>" and permutations thereof

UIs must capture the modifier and send it as "<D-...>" to vim_input().

Note: Before this commit, any arbitrary ":nnoremap <{foo}-{bar}>"
mapping could already be invoked with feedkeys("\<{foo}-{bar}>"). This
commit supports "D-" as a modifier that can be combined with "C-", "A-",
"S-" in any order.

For non-GUI (terminal) support, user must:
  :set <D-a>={CSI sequence}
then send the {CSI sequence} from their terminal. But this does not work
yet (regression #2204).

Closes #2190

Plugins (YCM, dispatch.vim) use gui_running to decide behavior; so do
some colorschemes. Up to now, nvim lied about gui_running for the
benefit of colorschemes and the detriment of all _other_ plugins that
check this condition. That's counterproductive: a user employs at most
_one_ colorscheme but may use many other plugins which expect the Vim
legacy semantics of gui_running.

Moreover, colorschemes usually don't _need_ to check gui_running: they
can instead set cterm{fg,bg} and gui{fg,bg} in the same :highlight call.

It is reasonable for users who want "true color" to modify their
colorscheme once (or request upstream to do so) in order to avoid
running into quirks in any other plugins.

Closes #2782

This is consistent with VIM behavior. When showing a visual selection,
VIM only extends it past the last character if eol is in listchars (even
if nolist is set).

Travis defines[1] $CI for its builds, whereas $CI_TARGET is
a Neovim-specific env var from 6483a198e4bee1e80683ba12e061616c3e6c4090
that lost prominence in d2eb4a934683b5da63000d8b79a0d4c9a314d1c0.

[1] https://docs.travis-ci.com/user/environment-variables/