Update JIT sources to clang-format/clang-tidy 17.0.6

[BruceForstall]

The version of clang-format/clang-tidy we use in the JIT is very old and needs to be updated: see #59545. One reason is to allow support for jit-format on arm64 Mac, and possibly arm64 Linux. Another is simply to better support newer language features and fix bugs.

This PR shows an updated clang-format configuration file that gets us about as close as possible to the formatting we currently have (it is impossible to get it 100% the same). There are some nice improvements here.

[BruceForstall]

I verified that I could jit-format on Windows x64, then jit-format on Mac arm64, and no additional formatting changes were made.

[BruceForstall]

@dotnet/jit-contrib @jkoritzinsky PTAL

[BruceForstall]

Related: #71983

cc @a74nh

Looks like the 17.0.6 release has some aarch64 Linux binaries: https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.6

[jkoritzinsky]

Do we get any benefits with LLVM 17 over 16? I'm asking as the rest of the LLVM build tool usages in our repo are on v16 currently and it would be nice to align them (and upgrade them in tandem).

[BruceForstall]

I'd rather go to the newest possible, and 17.0.6 was the latest that also had built Ubuntu binaries (as well as osx-arm64, windows-x64). I don't think we should tie the JIT use of clang-format/clang-tidy to any other use of LLVM; that just complicates dependencies and our ability to update.

[BruceForstall]

Note that this change requires dotnet/jitutils#408.

All the pieces are in place where we could take this change now. I've tested jit-format on linux-x64 (Ubuntu 22.04.4 LTS), win-x64, and osx-arm64.

[BruceForstall]

I updated the formatted code if you want to look, or look again.

[SingleAccretion]

I have went through the entirety of the change. The majority of it look great. In particular, it looks that it will now be possible to delete the CLANG_FORMAT_ANCHOR workaround.

There were, however, three patterns that looked problematic:
1) Code comments align together with those from #ifdefs, e. g.:

 #else  // !TARGET_ARM64
             // There is no zero register on ARM32
+       // There is no zero register on ARM32
             unreached();
 #endif // !TARGET_ARM64

I skimmed the Clang format document, it didn't look like it has specific options for this situation (comment aligning: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#aligntrailingcomments). Perhaps, this can be worked around in source with a whitespace:

 #else  // !TARGET_ARM64
+
             // There is no zero register on ARM32
             unreached();
 #endif // !TARGET_ARM64

Or deleting the ifdef comments in case of very short ifdefs.
2) Code aligns together with an if that is meant to be conditionally else if:

 #ifdef TARGET_XYZ
 if (...)
 {
     ...
 }
 else
 #endif // TARGET_XYZ
     if (...)
-{
-    ...
-}
+   {
+       ...
+   }

Not sure how to fix this. Maybe the by unindenting the second if manually?

 #endif // TARGET_XYZ
-    if (...)
+if (...)
 {
     ...
 }

3) Long comments on macros induce multi-line macros:

-#define CHECK_STRUCT_PADDING 0 // Set this to '1' to enable warning C4820 "'bytes' bytes padding added after
-                               // construct 'member_name'" on interesting structs/classes
+#define CHECK_STRUCT_PADDING                                                                                           \
+    0 // Set this to '1' to enable warning C4820 "'bytes' bytes padding added after
+      // construct 'member_name'" on interesting structs/classes

I guess it is not a big deal, but it does look worse.

There is also one miscellaneous change: closing braces after namespaces now get a comment:

-}
+} // namespace XYZ

Do we want it? (Can be turned off via https://clang.llvm.org/docs/ClangFormatStyleOptions.html#fixnamespacecomments).

[BruceForstall]

@SingleAccretion Thanks for looking!

1. Code comments align together with those from #ifdef

That one's odd. I think we'll have to work around it with additional whitespace.

2. Code aligns together with an if that is meant to be conditionally else if:

I think the best way to fix this is to avoid having "else" and "if" in separate #ifdef blocks, which IMO is already a readability problem.

3. Long comments on macros induce multi-line macros:

It doesn't happen too often, and I think the fix is to put non-trivial (i.e., multi-line) comments before the macros, e.g.,

// Set this to '1' to enable warning C4820 "'bytes' bytes padding added after
// construct 'member_name'" on interesting structs/classes
#define CHECK_STRUCT_PADDING 0

Related: I'd like to reformat a lot of jitconfigvalues.h this way, as it has far too many weirdly-formatted and multi-line comments.

There is also one miscellaneous change: closing braces after namespaces now get a comment:

Looks useful to me (I hadn't notice that one; we don't use namespaces too often).

[BruceForstall]

This is ready to go. It requires dotnet/jitutils#408 as well.

I tested the CI format job with #100565, which is the same as this PR but pulled the jitutils bootstrap.cmd/sh from my jitutils PR branch.

Note that osx-x64 is no longer supported for formatting (but osx-arm64 is!). (It might be possible if you build your own clang 17.0.6 osx-x64 clang-format/clang-tidy?)

I'd like someone to pull down this and the corresponding jitutils PR on an osx-arm64 machine to verify it works for them, as well.

@AndyAyersMS @jakobbotsch @dotnet/jit-contrib PTAL

[AndyAyersMS]

Thanks for doing this. The new format looks better.

[BruceForstall]

/ba-g Formatting job failures are expected due to required cross-repo coordinated checkin