Fix gbak output some errors and warnings to stderr instead of stdout

[XaBbl4]

Currently in standalone application mode when redirect to the standard stream, for example:
gbak ... > /path/to/stdout.log
some error and warning messages may be missed, which may cause inconvenience.

For example, during when restore we may see an error message:

gbak: ERROR:Database is not online due to failure to activate one or more indices.
gbak: ERROR:    Run gfix -online to bring database online without active indices.

but in order to find out which index remains inactive, we need to look at the entire log, and in it we can already find:

gbak:cannot commit index TEST_INDEX
gbak: ERROR:attempt to store duplicate value (visible to active transactions) in unique index "TEST_INDEX"
gbak: ERROR:    Problematic key value is ("ID" = 1)

Although in the global community it is accepted to output all errors and warnings to stderr.

This patch fixes this bug. I tried to cover all the cases found, but may have missed something.
I believe BURP_print_status should always output to stderr, regardless of whether the err argument is set to true or not. The err argument is now only responsible for setting status in service mode. Also BURP_print_warning should always output to stderr.

[AlexPeshkoff]

Earlier the following approach was used - errors that may be recovered by gbak were going to stdout, fatal - to stderr. I can agree that putting recoverable errors into stderr makes sense. Bit why not all? Something like:

         BURP_print(false, 171, relation->rel_name.toQuotedString().c_str());
         // msg 171: error committing metadata for relation %s

in restore.epp is left in stdout but

         BURP_print(true, 343, SafeArg() << int(attribute) << "put_asciz()" << (MAX_FILE_NAME_SIZE - 1));
         // msg 343: text for attribute @1 is too large in @2, truncating to @3 bytes

in backup.epp will go into stderr.

I want to know what criteria was used to keep some messages in stdout.

[XaBbl4]

Initially, during the restore, I tried to capture only those errors that didn't bring the database online when the utility terminated.

As I mentioned in the first message, I might have missed some places, as I couldn't reproduce every case; this is likely one of them.

In the backup, I moved all BURP_print calls to the error stream, not seeing the logic for splitting the output.
As for error 343, the code had a similar output in the put_text function, and put_asciz also sent it to the error stream.