Let ack(1) compile files with non-ASCII names.

Let ack(1) compile files with non-ASCII names.

This commit changes how ack(1) parses backslashes in its descr files.
Before this commit, ack set the high bit of each character escaped by
a backslash, and later cleared all high bits in command arguments, but
this lost the high bits in non-ASCII filenames.  After this commit,
ack keeps backslashes in strings while processing them.  Functions
scanvars(), scanexpr(), doassign(), unravel(), addargs() now
understand backslashes.  I remove from ack_basename() the warning
about non-ASCII characters.

This commit makes some incompatible changes for backslashes in descr
files.  None of our descr files uses backslashes, except for those
backslashes that continue lines, and there are no changes for those
backslashes.  The problem with non-ASCII filenames had its cause in a
feature that we weren't using.

With this commit, ack now understands backslashes after the = sign in
both "var NAME=value" and "mapflag -flag NAME=value".  Before, ack
never scanned backslashes in "var" lines, so "var A=\{B}" failed to
prevent expansion of B.  Now it does.  Before, ack did scan for
backslashes in the "-flag NAME=" part of "mapflag" lines.  Now it
doesn't, so it is no longer possible to map a flag that contains a
literal space, tab, or star "*".

I removed the expansion of "{{" to "{".  One can use "\{" for a
literal "{", and "\{" now works in "var" lines.  Before and now, ack
never expanded "{" in flags for "mapflag", so the correct way to map a
literal flag "-{" remains "mapflag -{ ...", not "mapflag -{{ ...".
(The other way "mapflag -\{ ..." stops working with this commit.)

Backslashes in strange places, like "{NA\ME}", probably have different
behavior now.

Backslashes in "program" lines now work.  Before, ack scanned for
backslashes there but forgot to clear the high bits later.

Escaping < or > as \< or \> now works, and prevents substitution of
the input or output file paths.  Before, ack only expanded the first <
or > in each argument.  Now, it expands every unescaped < or > in an
argument, but this is an accident of how I rewrote the code.  I don't
suggest to put more than one each of < or > in a command.  The code no
longer optimizes away its recursive calls when the argument is "<".

The code continues to set or clear the high bit NO_SCAN on the first
characters of flags.  This doesn't seem to be a problem, because flags
usually begin with an ASCII hyphen '-'.