More clang-tidy checks

[jcoupey]

This ticket is a follow-up from #911 with a braindump on checks that look interesting but would require further investigation.

cppcoreguidelines-init-variables

The proposed fixes consists in simply assigning the default type value for the non-initialized variable. This is the lazy solution: looking at examples often shows problematic patterns where a better design around the definition/use of the variable would fix the problem in a more robust way. This requires to go through all warnings and fix them before enabling the check.

performance-move-const-arg

I ruled out this check in #911. Could be worth going back to the suggested fixes to see whether we want them and enable the check.

bugprone-too-small-loop-variable

This check is interesting since it raises questions on how we currently mix our own Index type in loops with std::size_t. Theoretically, something like for (Index j = 0; j < jobs.size(); ++j) could be an infinite loop since Index is a "smaller" type and will overflow before reaching the stopping condition if jobs is really big.

I disabled the check for now since it is not just about putting the right type at the right place, we should actually make a decision on whether there is a limitation on various input sizes (number of vehicles, jobs etc.) and if yes how we enforce it.

cppcoreguidelines-special-member-functions

Probably something we want to enable at some point.

modernize-use-default-member-init

I did not expect the changes suggested by this one but I actually like the idea that it allows to rule out default member initializations from the ctors. The default value is provided along with the member declaration in the header file, and then constructors only initialize the members whose value depends on the ctor parameters.

Since the check only applied automatic fixes to built-in types, we should extend that rule for our custom types, which would help defining even more ctor using =default. Typical examples are values set to NO_EVAL or NO_GAIN in various ctors.

[jcoupey]

Most of this is probably covered in the sonarcloud analysis which makes it much easier to address. Closing here as superseded by #984 and #986.