cppcheck.cpp: Check for JSON error when parsing addon .json files

[versat]

This fixes that errors in JSON files given via --addon=*.json are
silently ignored and maybe only a part of the JSON file is used.
Now the error message which picojson can return is checked and a
corresponding error message is returned again by getAddonInfo().

[versat]

@danmar I guess this is not correct. It looks like this variable is meant for analysis errors. But in this case, it is an error in an input file. Is there a better way to set the exit code that also does not need --error-exitcode= beeing set?

[danmar]

For me this feels ok. It's serious if this does not work.

[jubnzv]

For information, it's already implemented in #2367 here (see also: tests and GUI integration). So we'll get errors handing after merging this changes, in next release, I think.

[versat]

For information, it's already implemented in #2367 here (see also: tests and GUI integration). So we'll get errors handing after merging this changes, in next release, I think.

Yes throwAddonError() is exactly what I would need here.
@danmar How shall we proceed? Change this PR to only print the error but behave like before and wait until after the release for throwAddonError()?

[jubnzv]

@versat I think it's better to merge it for now and replace it later. It is good if the user will have error messages in current release.

[versat]

I have added the possibility to check the naming of constants to naming.py. Without this enhancement, the addon does not make so much sense. Constants often are named different than normal variables, and Cppcheck is no exception here.

I had to loosen the naming validation rules in naming.json since there are some names that are hard or impossible to fix. For example, a constructor of a class that is inside another class seems to be not marked as a constructor. This results in false positives. So I allowed functions to begin with upper letters for now.
Another problem I do not yet know how to best solve are argument names beginning with underscore _. Code is like void f(int _var) { int var = _var}. So I allowed variable names to begin with an underscore for now.

I have fixed naming violations in CLI/LIB/GUI so Travis is happy now.
The plan is to make the naming rules more strict again and fix it in further PRs.
I did not want to create such a big PR, but fixing one thing resulted in other things that need fixing and so on :(
@danmar What do you think?

[danmar]

The plan is to make the naming rules more strict again and fix it in further PRs.
I did not want to create such a big PR, but fixing one thing resulted in other things that need fixing and so on :(

sounds like a good approach.