Will be fixed in the next commit.

In those versions of zsh, «[[ -o nosuchoption ]]» is regarded as
a syntax error.  In newer zsh versions, it merely returns non-zero
(specifically, it returns 3, unlike «[[ -o unsetoption ]]» which
returns 1).

Fixes #732.
Fixes #733.

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.

Fixes #727.

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.

Fixes #461.

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.

Part of issue #645.

Part of issue #645.

The escaped caret was taken for a negated character class.  This caused test-data/arith1.zsh
to XPass: the arithmetic expansion was consumed by the 'while' loop.

This is not perfect: we don't try to detect cases such as «$((ls); (ls))»,
which look like arithmetic expansions but are in fact command substitutions.

Fixes part of #607.

Introduces #704.

Fixes #694.

Fixes #583.

Fixes #582.