color-tests: coloring can be forced on non-ANSI terminals as well

color-tests: coloring can be forced on non-ANSI terminals as well

Before this change, colorization of testsuite output was suppressed
whenever the terminal was recognized to be a "dumb" one, incapable
of handling ANSI coloring (i.e., when the environment variable TERM
had a value of "dumb").  This happened even when the AM_COLOR_TESTS
variable was set to a value of "always".

Such a behaviour was suboptimal and slightly confusing; in fact, if
a user wants to force coloring of testsuite output that is being
redirected to a regular file, he should be able to do so even if his
terminal is not capable of handling ANSI colors -- in fact, such
terminal wouldn't be involved with the testsuite output in any way,
so why should it be allowed to influence it?

Thus, we now enable coloring of test output whenever AM_COLOR_TESTS
is set to "always", irrespective of the value of the TERM environment
variable.

* NEWS: Update.
* lib/am/check.am [%?COLOR%] (am__tty_colors): Activate colorization
of testsuite output whenever AM_COLOR_TESTS has the value of "always".
* t/ax/tap-summary-aux.sh: Export the TERM environment variable to
"dumb" when forcing colorization of the testsuite output; this should
*not* prevent such colorization from taking place, and we want to
check that this expectation really holds.
* t/ax/testsuite-summary-checks.sh: Likewise.
* t/color.sh: Likewise, and adjust some grepping checks.
* t/tap-color.sh: Likewise.  Also, remove redundant "make check"
invocation since we are at it.
* t/color2.sh: Likewise, and check that exporting TERM=dumb actually
prevents testsuite output colorization when AM_COLOR_TESTS is unset.
* t/parallel-tests-reset-term.sh: Relax, to prevent it from failing
spuriously due to the new semantic.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>