An error message was emitted on versions of zsh that don't have the
WARN_NESTED_VAR option.

Fixes #731.

Fixes #728, the performance regression from 0.7.1.

The overall per-highlighter duration should be less prone to random
noise than the multitude of per-test-file figures.

Without this patch, `_zsh_highlight` was invoked by add-zle-hook-widget
with `$?` being non-zero (see add-zle-hook-widget:48-52).  Since
`_zsh_highlight` preserves `$?` from its caller's point of view,
add-zle-hook-widget saw a non-zero exit code from `_zsh_highlight` and
did not run any the remaining zle-line-pre-redraw hooks.

See https://github.com/zsh-users/zsh-syntax-highlighting/issues/579#issuecomment-623576907.

Fixes #727.

Fixes #719.

Cf. #688.

Accidentally lost during a rebase.

As described in the last commit's log message, ${parameter_name_pattern]
explicitly matches positional parameters but ${parameters[$MATCH]}
expands to nothing in that case (when, e.g., [[ $MATCH == '1' ]]; note
this is equality of strings, not integers).

As a side effect, this removes the dependency on the zsh/parameter
module for expanding parameters.

On the test case, the behaviour was as follows:

+highlighters/main/main-highlighter.zsh:733> _zsh_highlight_main_highlighter__try_expand_parameter '$1'
+highlighters/main/main-highlighter.zsh:432> local arg='$1'
+highlighters/main/main-highlighter.zsh:433> unset reply
+highlighters/main/main-highlighter.zsh:439> local -a match mbegin mend
+highlighters/main/main-highlighter.zsh:440> local MATCH
+highlighters/main/main-highlighter.zsh:440> integer MBEGIN MEND
+highlighters/main/main-highlighter.zsh:441> local parameter_name
+highlighters/main/main-highlighter.zsh:442> local -a words
+highlighters/main/main-highlighter.zsh:443> [[ '$' != \$ ]]
+highlighters/main/main-highlighter.zsh:446> [[ 1 == { ]]
+highlighters/main/main-highlighter.zsh:449> parameter_name=1
+highlighters/main/main-highlighter.zsh:451> [[ none == none ]]
+highlighters/main/main-highlighter.zsh:451> zmodload -e zsh/parameter
+highlighters/main/main-highlighter.zsh:452> [[ ${parameter_name} -regex-match ^${~parameter_name_pattern}$ ]]
+highlighters/main/main-highlighter.zsh:453> [[ '' != *special* ]]
+highlighters/main/main-highlighter.zsh:456> case array-special (*array*|*assoc*)
+highlighters/main/main-highlighter.zsh:458> words=( '$1' )
+highlighters/main/main-highlighter.zsh:469> reply=( '$1' )

There are two problems here:

- In terms of _zsh_highlight_main_highlighter__try_expand_parameter's
  pre- and postconditions, the expansion of the word «$1» (line 733)
  included that same word (line 469).

  That happened because word-to-be-expanded is passed to
  _zsh_highlight_main_highlighter__try_expand_parameter as its first
  positional parameter, and in this case the word happened to be «$1».

- Furthermore, the exclusion of special parameters (line 453) false
  negatived.  That happened because $parameter_name_pattern explicitly
  allows positional parameters, but ${parameters[(e)1]} expands to
  nothing.  This will be fixed in the next commit.

Not a regression from 0.7.1.

Before this commit, if the value didn't begin with a dollar sign,
_zsh_highlight_main_highlighter__try_expand_parameter() would return 1
by accident.¹  Tweak the input validation to make this behaviour
explicit.  No functional change.

¹ Specifically, it would return 1 because ${parameter_name}'s value
would be the empty string and ${parameter_name_pattern} wouldn't match
that.

This is in order to allow it to be reused.

No functional change.

The new implementation is less efficient but definitely correct.

This reverts commits ea7c165b59 and
3d81c83132.

When "have 6 expectations and 4 region_highlight entries", the pure-zsh
implementation printed them as follows:

    not ok 7 - cardinality check - have 6 expectations and 4 region_highlight entries: «expected_region_highlight=( $'1 1 builtin' $'3 6 comment' $'8 13 comment' $'15 15 default' $'16 21 comment' $'22 22 default' )»
    «region_highlight=( $'0 1 builtin' $'2 6 comment' $'7 13 comment' $'14 22 default' )»
    # expected_region_highlight  '22 22 default'
    # '1 1 builtin'              region_highlight
    # '3 6 comment'              '0 1 builtin'
    # '8 13 comment'             '2 6 comment'
    # '15 15 default'            '7 13 comment'
    # '16 21 comment'            '14 22 default'

Whereas the column(1)-based implementation prints them as follows:

    not ok 7 - cardinality check - have 6 expectations and 4 region_highlight entries: «expected_region_highlight=( $'1 1 builtin' $'3 6 comment' $'8 13 comment' $'15 15 default' $'16 21 comment' $'22 22 default' )» «region_highlight=( $'0 1 builtin' $'2 6 comment' $'7 13 comment' $'14 22 default' )»
    # expected_region_highlight  region_highlight
    # '1 1 builtin'              '0 1 builtin'
    # '3 6 comment'              '2 6 comment'
    # '8 13 comment'             '7 13 comment'
    # '15 15 default'            '14 22 default'
    # '16 21 comment'
    # '22 22 default'

Ultimately, this difference is down to the pure-zsh implementation
getting the arguments as a single list, whereas paste(1) gets two
separate lists.

Command position: non-executable files, non-cdable directories, CDPATH false positives

Fixes #461.

(q-) passes through newlines and NUL bytes verbatim.  Using (qqqq) ensures the
escaped string will be on a single line (as required by the TAP format) and be
readable even if it contains control characters.

Fixes #475.

Fixes #504.

Fixes #202.

Test expectations are updated.  For example, BUFFER='/bin' is now
highlighted as path_prefix because it's a prefix of '/bin/sh' which
would be valid.  However, BUFFER='/bin;' is now properly highlighted
as an error (unless AUTO_CD is set).

The next commits will change this behaviour.

Fixes #430.

Will be fixed in the next commit.