Add .clang-format and run clang-format -i *.cpp

[est31]

It seems to me the original intent of the code style of the
LLVM wrapper was to follow the LLVM format. However, code style has
gotten a bit inconsistent inside the files. Thus, we add a
.clang-format file that indicates that the LLVM format is followed,
and run clang-format -i *.cpp on the files.

I file this PR as a request-for-comment. Please suggest some other code style if you prefer it. clang-format has a rich set of configuration options.

Also I wonder if CI should enforce this. It's easy to do, one just has to run clang-format --dry-run --Werror *.cpp in the llvm-wrapper directory. Should it maybe be added to tidy?

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

cc @rust-lang/wg-llvm

I'm not personally entirely against this, but I think it may not make sense for us to check this in CI at least unless we can provide a smooth integration path to obtaining clang-format (I guess of the appropriate version).

[cuviper]

I think having .clang-format will be strictly better than the current free-for-all, even if the exact tool version is uncertain.

[Mark-Simulacrum]

You mean just opportunistically permitting reformats to that style? Yes, that seems reasonably OK to me.

[est31]

It's only a couple of thousand lines. There shouldn't be that large changes between versions of clang-format.

[nagisa]

If it isn't enforced by the CI, I don't see too much value in an one-off PR to format the code. Eventually the formatting will diverge again. It isn't like we've too atrocious formatting as it is right now, either, right?

Also formatting changes are a pain to git blame through in general, so it better be a one-time ordeal.

[bors]

☔ The latest upstream changes (presumably #83894) made this pull request unmergeable. Please resolve the merge conflicts.

[est31]

Hmmm there seems to be little enthusiasm for this change, and I guess it's only 2 thousand lines so whatever.