Update and enforce formatting for C/C++ (#1474)

[AMS21]

Every new commit or pull request will now be checked with clang-format.
Note that only violations in new code will be reported and any old code will stay just as it is.

Here is an example PR to showcase how this would look like.

[AMS21]

Rebased and update to LLVM 18

[AMS21]

Rebased and updated to LLVM 20
@Xottab-DUTY Thoughts on getting this merged?

[Xottab-DUTY]

Rebased and updated to LLVM 20 @Xottab-DUTY Thoughts on getting this merged?

I need to check that .clang-format corresponds to our code style, which currently has some relaxed requirements:
We generally follow the naming style of a certain file or a certain class. It can be a developer preference if the naming style of the class or file is already mixed. Generally, there are two choices for naming:

1. PascalCase based variable naming
   • All global/public variables and both private/public functions should be in PascalCase
   • Local/private variables should be in camelCase
   • Using camelCase for global/public variables is strongly discouraged, but can be used if the entire class or a file follows it and not using it would look alien. Renaming to PascalCase should be considered
   • Hungarian notation is discouraged, but can be used if the entire class or a file follows it and not using it would look alien. Renaming in spare time should be considered
   • Template parameter names should be in PascalCase
2. snake_case based variable naming
   • non-static global variables should have g_ prefix
   • static global variables should have s_ prefix
   • global constexpr variables should be upper case, omitting g_/s_ prefixes
   • local constexpr variables can be named like global constexpr variables or just like generic variables
   • private member variables in classes should have m_ prefix, public members should not have this prefix
   • Template parameter names should be in PascalCase

As for formatting style, here are some rules:

• Braces always should be on a new line if it's a code block/scope

  • if (condition) { // not allowed
    
    if (condition)
    { // correct

  • One-line lambda-functions is ok. Writing standard functions in one-line is discouraged
• Braced initializers should always have spaces inside

  • auto vec = Fvector{1,2,3}; // incorrect!!
    auto vec = Fvector{1, 2, 3}; // incorrect
    auto vec = Fvector{ 1, 2, 3 }; // correct

• Preprocessor directives should be indented, leaving the # at the beginning of the line

  • #if defined(A)
    #   define B
    #   if defined(C)
    #       define D
    #   endif
    #endif
    

For third-party dependencies, we should strictly follow their code style.

[Xottab-DUTY]

Much thanks for this gem!