CI: Update clang-format pre-commit hook to latest version

[Repiteo]

Accompanies #93271

Updates clang-format to the latest available version: 18.1.6. This will largely sync the hook with what is used in IDEs, as those tend to use the latest version when applicable. Additionally modernized the .clang-format file to sync with llvm's settings on the latest version. All uncommented rules remain as they were in the prior version, with the only difference being replacing the now-removed ConstructorInitializerAllOnOneLineOrOnePerLine: true with the modern equivalent PackConstructorInitializers: NextLine.

It seems some more default enforcements have been made since then, as well as general parsing improvements. As such, there's another commit applying clang-format across the repo (only whitespace changes) & excluding it in .git-blame-ignore-revs with a subsequent commit.

[Repiteo]

Decided to expand the scope of this PR slightly to include that aforementioned semicolon fix, as there was fairly significant overlap between the files that would've been affected.

[AThousandShips]

Upgrading clang-format version might affect various workflows so I think it's something to take a deep look into, I think we shouldn't just focus on the hook but manual use and different possible targets and OSs running it as well

[Repiteo]

Hmm, that's a fair point. I'll go back to my original idea and make the semicolon fix separate so this can focus on clang-format instead.

[AThousandShips]

I think doing that separately might be good, though it is a bit of a sweeping change but with blame ignoring it won't create noise so I think it's worth it (though it might create some annoying conflicts)

[Repiteo]

I believe some form of update should happen regardless to clang-format, as right now the live hook version (v17.0.6) doesn't match the live last-synced version (v14.0). Additionally, the clang-tidy hook on live is modernized at v18.1.1; while not integrated in any workflow atm, I think it's reasonable to have major/minor versions the clang tools synced. Granted, this could be inversely applied by bumping clang-tidy down to 17.x; I'd be fine with that, but still ultimately prefer keeping these tools as updated as possible.

[akien-mga]

Should we remove these empty _bind_methods? What's the point of overriding the virtual method to do nothing?

[akien-mga]

(Post from the past, seems like I had forgotten to send my review...)

[Repiteo]

Ehh, I'll leave it be; I'd rather keep all the changes strictly stylistic.

[akien-mga]

I had missed that one in my own PR, but that's another new clang-format bug :\

It's always been hit and miss on our custom glsl with bits of invalid syntax we replace at compile time.

I think we've accepted to just live with it, though I wonder why this is now changing when it didn't before.

[akien-mga]

One option if we don't want this to happen is to just disable clang-format around this layout definition:

diff --git a/servers/rendering/renderer_rd/shaders/canvas.glsl b/servers/rendering/renderer_rd/shaders/canvas.glsl
index e64dd17072..fb813c5ab2 100644
--- a/servers/rendering/renderer_rd/shaders/canvas.glsl
+++ b/servers/rendering/renderer_rd/shaders/canvas.glsl
@@ -41,10 +41,13 @@ layout(location = 3) out vec2 pixel_size_interp;
 #endif
 
 #ifdef MATERIAL_UNIFORMS_USED
+/* clang-format off */
 layout(set = 1, binding = 0, std140) uniform MaterialUniforms {
+
 #MATERIAL_UNIFORMS
-}
-material;
+
+} material;
+/* clang-format on */
 #endif
 
 #GLOBALS

We already do that in a number of places in .glsl shaders, e.g. in drivers/gles3/shaders/scene.glsl:

/* clang-format off */
layout(std140) uniform MaterialUniforms { // ubo:3

#MATERIAL_UNIFORMS

};
/* clang-format on */

CC @clayjohn

[Repiteo]

I'll disable clang-format for those blocks. Really wish there was a way to ignore single lines like clang-tidy…

[akien-mga]

Thanks!