Firstly fix FileCheck printing string variables
double-escaped (first regex, then C-style).
    
This is confusing because it is not clear if the printed
value is the literal value or exactly how it is escaped, without
looking at FileCheck's source code.
    
Secondly, only escape when doing so makes it easier to read the value
(when the string contains tabs, newlines or non-printable characters).
When the variable value is escaped, make a note of it in the output too,
in order to avoid confusion.
    
The common case that is motivating this change is variables that contain
windows style paths with backslashes. These were printed as
`"C:\\\\Program Files\\\\MyApp\\\\file.txt"`.
Now prefer to print them as `"C:\Program Files\MyApp\file.txt"`.
Printing the value literally also makes it easier to search for
variables in the output, since the user can just copy-paste it.

For #145865

This reverts commit 9d98acb196a40fee5229afeb08f95fd36d41c10a.

This reverts commit dccebddb3b802c4c1fe287222e454b63f850f012.

Line ending policies were changed in the parent, dccebddb3b80. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.

Historically, we've not automatically enforced how git tracks line
endings, but there are many, many commits that "undo" unintended CRLFs
getting into history.

`git log --pretty=oneline --grep=CRLF` shows nearly 100 commits
involving reverts of CRLF making its way into the index and then
history. As far as I can tell, there are none the other way round except
for specific cases like `.bat` files or tests for parsers that need to
accept such sequences.

Of note, one of the earliest of those listed in that output is:

```
  commit 9795860250734e5c2a879546c534e35d9edd5944
  Author: NAKAMURA Takumi <geek4civic@gmail.com>
  Date:   Thu Feb 3 11:41:27 2011 +0000

      cmake/*: Add svn:eol-style=native and fix CRLF.

      llvm-svn: 124793
```

...which introduced such a defacto policy for subversion.

With old versions of git, it's been a bit of a crap-shoot whether
enforcing storing line endings in the history will upset checkouts on
machines where such line endings are the norm. Indeed many users have
enforced that git checks out the working copy according to a global or
per-user config via core crlf, or core autocrlf.

For ~8 years now[1], however, git has supported the ability to "do as
the Romans do" on checkout, but internally store subsets of text files
with line-endings specified via a system of patterns in the
`.gitattributes` file. Since we now have this ability, and we've been
specifying attributes for various binary files, I think it makes sense
to rid us of all that work converting things "back", and just let git
handle the local checkout. Thus the new toplevel policy here is

    * text=auto

In simple terms this means "unless otherwise specified, convert all
files considered "text" files to LF in the project history, but check
them out as expected on the local machine. What is "expected on the
local machine" is dependent on configuration and default.

For those files in the repository that *do* need CRLF endings, I've
adopted a policy of `eol=crlf` which means that git will store them in
history with LF, but regardless of user config, they'll be checked out
in tree with CRLF.

Finally, existing files have been "corrected" in history via `git add
--renormalize .`

End users should *not* need to adjust their local git config or
workflow.

[1]: git 2.10 was released with fixed support for fine-grained
line-ending tracking that respects user-config *and* repo policy. This
can be considered the point at which git will respect both the user's
local working tree preference *and* the history as specified by the
maintainers. See
https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248
for the release note.

Reland #82595 with fixes of build failures related to colored output.
See https://lab.llvm.org/buildbot/#/builders/139/builds/60549
Use `%ProtectFileCheckOutput` to avoid colored output.
Original commit message below.

In `Pattern::parseVariable`, for global variables (those starting with '$')
and for pseudo variables (those starting with '@') the first character is
consumed before actual variable name parsing. If the name is empty, it
leads to out-of-bound access to the corresponding `StringRef`.

This patch adds an if statement against the case described.

Reverts llvm/llvm-project#82595

See build failure
https://lab.llvm.org/buildbot/#/builders/139/builds/60549

In `Pattern::parseVariable`, for global variables (those starting with
'$') and for pseudo variables (those starting with '@') the first
character is consumed before actual variable name parsing. If the name
is empty, it leads to out-of-bound access to the corresponding
`StringRef`.

This patch adds an if statement against the case described.

Fixes #70221 

Fix a bug in FileCheck that corrects the error message when multiple
prefixes are provided
through --check-prefixes and one of them is a PREFIX-NOT.

Earlier, only the first of the provided prefixes was displayed as the
erroneous prefix, while the
actual error might be on the prefix that occurred at the end of the
prefix list in the input file.

Now, the right NOT prefix is shown in the error message.