Reodered ErrorMessage constructor parameter message and ID parameters

[GNL10]

No description provided.

[GNL10]

I made sure that I covered all the usages of these constructors by forcing compilation errors (normal compilation, compiling the UTs as well).
If there are pieces of code that could use these constructors but are not getting compiled with these commands (and are not being tested), I probably missed them.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.6% Duplication on New Code

See analysis details on SonarQube Cloud

[danmar]

I don't really see the advantage with this reordering. It looks rather dangerous. I don't understand how you made sure that all ids and messages are reordered - you said something about a compiler error.

I appreciate you try to fix something here.. would you like some suggestions for bugs that you can look at?

[GNL10]

I was just fixing the TODO that is in the code. The main advantage is simply to give consistency to the order of the msg and id fields in the multiple constructors of ErrorMessage.
After this MR they will all have the same order.

Regarding the compiler error, I was just mentioning that in order to find all applicable instances of the constructor, I forced a compiler error to happen specifically in these constructors that I updated. Then I updated the parameters in all of them and then I reverted the change that triggered the compiler error.

Sure I can take suggestions for bugs to look at!

[danmar]

sorry for slow reply. I was at cppcon last week and was extra busy before it..

Sure I can take suggestions for bugs to look at!

Thanks! How about this one:

https://trac.cppcheck.net/ticket/14126

If you can make sure that a syntaxError is written instead that would be great. A testcase in test/testgarbage.cpp would be nice.

The syntaxError is normally reported by Tokenizer::findGarbageCode but it seems it's executed after the crash.