Configure ci clang tidy report

[filipe-cuim]

Description

The goal of this PR is to configure a .clang-tidy that respects openbsw coding conventions, and a ci job that runs clang-tidy checks on all compilation units that are generated in compile_commands.json.

In this first step we start with fewer clang-tidy checks enabled, because currently with all checks enabled the repository has around 3924 findings (excluding all files in test, 3rdparty and mock) and around 23386 findings (when excluding only 3rdparty folder).

Each clang-tidy CI workflow will print a report of all findings for each checker in stdout. After that it will also upload an artifact with a yaml file generated by clang-tidy, which will contain the location (both file name and file offset) of all findings.

There may also exist some checkers that we do not want to activate, and as such it's better to do small PRs after this one, where only few checkers are considered, in order to limit the amount of changes in the repository.

[filipe-cuim]

Hello @rolandreichweinbmw @christian-schilling @hbragge-acn @johannes-esr let's maybe move the discussion here. In this PR I followed the suggestion of doing a full report of clang-tidy findings, instead of just checking a diff.

I tried to fix some of the warnings, but I didn't do it for all of them. There is a commit that addresses only one of the checkers.

I also focused on the posix build, and as such you will find in the s32k1xx build some warnings that supposedly were cleaned up in some of the commits.

There is also some clang-diagnostic-error which I'm not yet sure how to solve. These happen because clang-tidy looks to each compilation unit that is written in the compile_commands.json, and apparently some of these have invalid targets for unit test builds, and because of this CMake ignores those targets, and as such the compile commands becomes incomplete.
Usually these are libraries that depend on something from platforms which is not included in the unit test build, while their unit tests have the correct dependencies (which are different than the dependencies present in the library). An example is the CMake of bspOutputManager which depends on bspIo, while its unit tests depend on utbspIo.
Not sure if I should change the name of the targets to be the same for all (both target and unit test), or if I should change the CMakes somehow so that the compile_commands.json doesn't generate an entry for each library (and instead just for each executable for example).

Let me know what you think. Also, the checkers that I introduced came from a previous project, so I'm not really enforcing them. We may remove the ones you don't want to have.

[rolandreichweinbmw]

Only put a few remarks.

Also: Are the included "Fix" commits directly related to clang-tidy findings? E.g. directly enabling a clean acceptable baseline? Otherwise, "unrelated" changes could be separated out to a cleanup PR.

[filipe-cuim]

Only put a few remarks.

Also: Are the included "Fix" commits directly related to clang-tidy findings? E.g. directly enabling a clean acceptable baseline? Otherwise, "unrelated" changes could be separated out to a cleanup PR.

Theoretically yes, each commit is respective to one clang-tidy finding. So, in principle, if I remove one commit the PR should remain clean, or at least not needed many rebase changes