Dosbox-staging: Some warnings counts are not reliable

Once we started counting compiler warnings in all the jobs and all compilers, we seem to be immediately hit by warnings numbers appearing inconsistent for some configurations.

At least one of causes behind this is: logs from several compilation jobs are being merged unreliably (not line-by-line), while count-warnings script depends on a warning being reported in a single line e.g.:

https://github.com/dreamer/dosbox-staging/runs/318215850#step:6:20 (227 warninigs)
https://github.com/dreamer/dosbox-staging/runs/318228442#step:6:20 (210 warnings)

The difference is in format (-9), deprecated-declarations (-7), and deprecated-register (-1). I started investigation with deprecated-register, and in the actual number of warnings is the same in both logs (9), but script does not count one occurence because of this:

https://github.com/dreamer/dosbox-staging/runs/318228442#step:5:786

It should look like this:

./render_templates_sai.h:188:4: warning: 'register' storage class specifier is deprecated and incompatible with C++17 [-Wdeprecated-register]
                        register int r = 0;
                        ^~~~~~~~~

but looks like this:

./render_templates_sai.h:188:4: warning: 1 warning generated.
'register' storage class specifier is deprecated and incompatible with C++17 [-Wdeprecated-register]
                        register int r = 0;
                        ^~~~~~~~~

(not sure why Clang decided to issue this warning for code compiled with C++11, but that's besides the point)

Text 1 warning generated/X warnings generated seems to be issued only on Clang.

What is the exact root cause? I'm not sure, candidates being:

• maybe we shouldn't merge stdout with stderr to compile build.log (but it seems to work ok for GCC)?
• maybe Clang some issues with buffering output? (I find it unlikely)
• maybe colorized output contributes to the problem (e.g. by triggering binary output in Clang or something)

Running compilation with -j1 is not acceptable in my opinion, and we avoided it so far only because top-warnings job happened to be GCC. The issue is not macOS specific, it happened to Clang on Linux as well.

@krcroft any ideas how to resolve this and keep th clang warnings count usable?