Either avoid or silence expected casts from int to char.

I'm not entirely sure whether vStringPut() shouldn't actually take a
char argument instead of an int, as it will cast it in all cases. It is
however slightly more convenient as the APIs to retrieve characters
uses int only for edge cases (e.g. EOF), so the common case is a safe
cast and it's more convenient not to explicit it everywhere.

We expect an `unsigned char` passed as an `int`.  Anything else is
invalid and probably means there is an issue in the calling code.

Co-Authored-By: Masatake YAMATO <yamato@redhat.com>

vStringPut() and friends take an `unsigned char` as an `int`, similar
to ctype functions, in order to be easy to use with `fgetc()`-style
functions.

However, this API is also used on regular C strings, which require a
cast if the value is larger than 0x7F (127) on systems where `char` is
a signed type.

In order to make the API easier to use, as it's easy to forget the cast
when working with `char`, introduce wrapper macros that add the cast
when called with `char`.  The cast is conditional so the underlying
implementation can still verify the value is in the valid range when
called with an `int` (to catch erroneous calls with EOF or other values
that do not fit a `char`).

Note that this will still not work properly if the caller has an
incorrect cast on its side, like e.g. `vStringPut(s, (int) c)` where
`c` is a `char`, as there's only so many magic tricks up our sleeves.
These calls should be updated to either be `vStringPut(s, c)` with the
added macros, or `vStringPut(s, (unsigned char) c)` if one wants to be
explicit -- yet no need to go all the trouble to make them
`vStringPut(s, (int) (unsigned char) c)`, as the `unsigned char` to
`int` conversion is implicit and safe.

Based off a suggestion from Masatake YAMATO <yamato@redhat.com>

`vStringPut()` has been made forgiving in the type the character is
pass as in e6e018b.  It however
requires the value to be valid in one of the formats it accepts.

This commits should update all problematic cases, basically removing
all explicit casts:

* removing incorrect `int` to `char` casts;
* removing incorrect `char` to `int` casts;
* removing unnecessary `char` to `unsigned char` casts.
* removing unnecessary `unsigned char` to `int` casts.

Incorrect casts can lead to unexpected results with values > 0x7F.
Unnecessary casts make the code harder to read than necessary, and
risk being incorrectly copied to code where they would be incorrect.

`cppGetc()` can return `CHAR_SYMBOL` and `STRING_SYMBOL` which need to
be properly handled when trying to represent as character.