Correct highlighting of backslash escapes within "" strings: highlight only
the four specific escape sequences defined there.

Fixes zsh-users/zsh-syntax-highlighting#196.

Found by code inspection; WARN_CREATE_GLOBAL missed this.

Fixes zsh-users/zsh-syntax-highlighting#23.

Now, «"$42foo"» doesn't highlight the «foo», and «"$bar» highlights the «r».

Set WARN_CREATE_GLOBAL to prevent recurrence.

Fixes zsh-users/zsh-syntax-highlighting#192.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

* highlighters/main/test-data/hashed-command.zsh:
    Set the right region key.  This makes the test more specific.
    (Issue #184 would have caught this bug.)

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This was broken by c2b9327b07
and tracked as zsh-users/zsh-syntax-highlighting#199.

This fixes the vanilla-newline.zsh test, which was was (consciously) broken
by the previous commit.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

This is part of issue zsh-users/zsh-syntax-highlighting#198.

Notably, the 'single-hyphen-option' and 'assign' contexts both default to the
'none' style, so before this patch, the tests would not have detected a failure
to apply those two contexts.

For other contexts, using $unused_highlight only helps detect the case where
the right highlight style (e.g., 'fg=yellow') is used as a result of applying
the wrong context — which should be a theoretical failure mode.

This is part of zsh-users/zsh-syntax-highlighting#198.

The path string ends at offset 26, not 23.

This exercises the previous patch.

Fixes issue #195.

This does not yet highlight backslash escapes within them.

Add an underline, since they are at command word position but will be executed
by something else.

Suggested-by: Daniel Hahler

Fixes zsh-users/zsh-syntax-highlighting#94.

Fixes zsh-users/zsh-syntax-highlighting#126.

Fixes zsh-users/zsh-syntax-highlighting#189.

'local' is a reserved word in zsh 5.1 but not in earlier versions [1].
Therefore, under zsh older than 5.1, quoting is required.

This manifested as random «builtin=''» in emitted to the terminal, and
commands (such as 'echo') highlighted as errors (in red).

[1] https://github.com/zsh-users/zsh/blob/master/README#L46
    (the section "Incompatibilites between 5.0.8 and 5.1")

Similar to zsh-users/zsh-syntax-highlighting#97.

Fixes zsh-users/zsh-syntax-highlighting#181.

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

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