optimized deserializing of ErrorMessage and related main process code

[firewave]

When analyzing ruby-lapack it will rarely use all the available processes because the files are being analyzed very fast and produce a lot of output which requires parsing thus preventing from new processes being spawned fast enough.

I came across this quite a while ago but didn't have an actual case to test it with.

This improves things but there's more to be optimized. Will go into some less straight forward things in other PRs as well as tickets.

[firewave]

This still needs improved errorhandling.

[firewave]

The utilization of the processes is still non-existent from some point but it's a bit better.

Benchmark 1: bin/cppcheck --library=posix --library=gnu  --showtime=top5 --check-library --inconclusive --enable=style,information --inline-suppr --suppress=unmatchedSuppression --template=daca2 --debug-warnings --suppress=autoNoType --suppress=valueFlowBailout --suppress=bailoutUninitVar --suppress=symbolDatabaseWarning --suppress=valueFlowBailoutIncompleteVar -D__GNUC__ --platform=unix64 -j5 /mnt/s/Downloads/ruby-lapack-1.8.2 2> /dev/null

before:

  Time (mean ± σ):     207.301 s ± 10.444 s    [User: 263.947 s, System: 60.336 s]
  Range (min … max):   190.049 s … 214.663 s    5 runs

after:

  Time (mean ± σ):     175.161 s ±  3.506 s    [User: 224.577 s, System: 54.583 s]
  Range (min … max):   171.116 s … 178.383 s    5 runs

after with -j1:

  Time (mean ± σ):     110.920 s ± 15.305 s    [User: 99.366 s, System: 6.968 s]
  Range (min … max):   97.794 s … 134.904 s    5 runs

[firewave]

With some start-up optimization and some more improvements:

  Time (mean ± σ):     164.771 s ±  4.923 s    [User: 209.414 s, System: 50.433 s]
  Range (min … max):   159.761 s … 172.304 s    5 runs

[firewave]

"Ir count" using only the first 20 files from the package with the same parameter for the main process:

Clang 14 193,310,705 -> 101,474,166