Fixes zsh-users/zsh-syntax-highlighting#146

Given the following input:
    PREBUFFER=$'echo "foo\n'
    BUFFER='bar"'
This patch causes the '"foo' part to be highlighted as a string.  There
is no test because the tests only check highlighting of BUFFER, and 'bar"'
is already highlighted correctly.

The new function will be used in the next commit.

by extending the already in place mechanism of checking for the first
histchar to check for the second as well

If one defines aliases like `++` the alias builtin tries to interprete these
as options so they have to be protected like this

    alias -- ++=true

The same goes for a call to `alias` in order to expand the alias again.

This code is more lenient than bash.  Examples:

    $ x[y[]=
    zsh: no matches found: x[y[]=
    $ x[][]=
    zsh: no matches found: x[][]=

The proper solution is to look inside the [...] and make sure that all
unescaped/unquoted square brackes are matched, but that is a heck of
a lot more complicated than this simple 8-character patch.

Zsh does not allow the variable name or the equals sign to be quoted or
escaped.  The previous code incorrectly highlighted the following
examples as assignments:

    $ 'x=y'
    zsh: command not found: x=y
    $ x\=y
    zsh: command not found: x=y
    $ "x"=y
    zsh: command not found: x=y
    $ \x=y
    zsh: command not found: x=y

Leaking a variable that holds a path in CDPATH could easily end up appearing on your prompt like `~cdpath_dir/subdir`.

Parse sudo command line in order to highlight the options correctly

Comments added

Add support of CDPATH

Prepended an 'if' to remove error bell on osx systems.

Signed-off-by: Takeshi Banse <takebi@laafc.net>

Signed-off-by: Takeshi Banse <takebi@laafc.net>

Signed-off-by: Takeshi Banse <takebi@laafc.net>

Signed-off-by: Takeshi Banse <takebi@laafc.net>

* use a nicer variable name