PR14927: add -C switch for color in staprun/io

Also make stap send the -C switch if itself it was called with --color.
As opposed to the --color switch of stap, the WHEN argument was made
mandatory here so that it's consistent with the others, and it doesn't
conflict with the MODULE argument (and users don't have to resort to
using e.g. '-Cauto').

A few formatting fixes in the staprun manual page.
PR14927: remember original color mode to pass to staprun
PR14927: add parsing of SYSTEMTAP_COLORS

Add the parse_stap_color() function to parse out the color sequence of
wanted string types from SYSTEMTAP_COLORS.
PR14927: change wording in some call sites to err() and perr()

Following the changes from the previous commit, all calls to err() and
perr() were checked so that they were consistent with the prefix
"ERROR:" added by those macros.

Where err() was used to report non-critical information, it was
replaced by eprintf(), and where it was used for warnings, it was
replaced by the warn() macro.
PR14927: adjust testsuite for staprun/io string changes
make STP_OOB_DATA treatment more stringent

Since all STP_OOB_DATA originally comes from _stp_vlog() in
runtime/linux/io.c, we can be sure that all warnings will be prefixed
by "WARNING: " and all errors by "ERROR: ", as defined by WARN_STRING
ERR_STRING in io.c.

Therefore, we can be more stringent in control.c and mainloop.c in the
way we identify warnings and errors. Additionally, warnings can instead
use the warn() macro and errors the err() macro so that they benefit
from coloring.

The main effect of this patch is that all calls to _stp_warn() and
_stp_error() will be colored upon reception by stapio.
PR14927: enable coloring for stap and staprun/io by default

The default coloring mode was changed from 'never' to 'auto'.
Additionally, the terminal is now checked to make sure that it is not
dumb (i.e. it understands ANSI codes). Finally, to make sure that the
color sequences don't affect the testsuite, the latter was changed to
impersonate a dumb terminal.
PR14927: protect terminal from invalid vals in SYSTEMTAP_COLORS
PR14927: make stap use same parser as staprun for consistency

In order to ensure that both stap and staprun react the same way to
various values of SYSTEMTAP_COLORS, the parsing method in staprun was
copied to replace the one in stap (with small C++ adjustments).

This will also allow us to test both stap and staprun using the same
test cases (see the next commit).
PR14927: add new testcase color_parsing.exp

To make sure that the parser implemented for PR14927 is correct and
safe, this new testcase sets SYSTEMTAP_COLORS to various erroneous
values and verifies that both stap and staprun react accordingly.
PR14927: fix indentation and small compare() bug
parser: print a warning in case of suspicious }% embedded-c non-closer
PR14927: stapdyn: add -C switch

Also clarified usage of -C in staprun to indicate that auto is now the
default coloring mode.
PR14927: fix inheritance of color mode to staprun and stapdyn from stap

Added the -C switch in the building of the cmd for stapdyn. Also, since
the default color mode is now auto, we must check if the currently
active mode is anything other than auto before explicitly passing the -C
switch to staprun or stapdyn.
PR14927: stapdyn: add colorization for stapwarn() and staperror()

The colorize() and parse_stap_color() functions are the same as in
session.cxx.
PR14927: make more warnings from staprun/stapdyn sensitive to -w

Before, even with the -w option specified for staprun, some warnings
(such as when the child process exits with a nonzero code) were still
output. Now, all warnings are affected by -w.

A similar operation was carried out in stapdyn, where the use of warnx()
was changed to stapwarn() so that -w now silences them. This changes
also gives those warnings the chance to be colored if necessary.
PR14927: stapdyn: make warning/error string capitalization consistent

Just like in stap and staprun, where messages that follow the "WARNING:"
and "ERROR:" string are capitalized.
token colorizer: eschew tok_embedded etc. types

When printing source context for an error, we don't really know how
many characters from the source to highlight for any given token, as
that only stores the starting column position.

The tok->content.size() is a guide, but not a perfect one, as for some
(tok_string, tok_embedded, ...), the content is processed from the
source characters (with quotation signs removed, etc.), for others,
the tok->content() can be many lines long.  That's a problem because
if we try to source_line.substr(..., long_multiline_token.length()...),
we'll get a SEGV.

So we colorize only those tokens whose type is known to be simple and
literal transcriptions of the source file, starting at
column=tok->column.
PR14927: change error messages from using warn/x() to staperror()

There are two main reasons for this:
1. Using staperror() will preface the errors with an "ERROR:" string,
   which may be colored, depending on the coloring mode.
2. The use of warn() and family are not recommended as they are provided
   only for compatibility with BSD.
Improve buildok-dyninst.exp test results a bit.

* testsuite/systemtap.pass1-4/buildok-dyninst.exp: Add kfail for
  buildok/fortyseven.stp.
* testsuite/buildok/gtod_init.stp: Only look for 'STAP_NEED_GETTIMEOFDAY'
  when using the kernel runtime.
* testsuite/buildok/gtod_noinit.stp: Ditto.