[clang] [clang][Python] Use fstrings instead of string concatenations (PR #173861)

[Jannick Kremer via cfe-commits]

DeinAlptraum wrote:

> CC @DeinAlptraum if you think f-strings are an improvement, that's your chance to convince me.

Okay, I don't have particularly strong opinions on this, but here are my thoughts:

TLDR: I think f-strings are generally preferable, but not to the point that I see a need to enforce their usage. C-style formatting should be avoided, but `str.format()` is perfectly fine (and sometimes preferable)

Longer version:
1. I personally agree that f-strings are the best in terms of readability. The majority of string formatting in the bindings currently uses old C-style formatting, which should be avoided (it's un-pythonic, generally not recommended, and annoying to format/easy to break due to wrong typing). I also think that putting the values to be interpolated directly in the string, rather than at the end, is easier to read. That said, complex expressions in the middle of a string (e.g. the `" | ".join` around line 3190) or cases that necessitate excessive or hard-to-read escaping (e.g. `f"{{'{self.spelling}` around line 3070) should be avoided: in those cases `str.format()` (possibly with named placeholders) are easier to read imo.
2. Performance: I did a quick test iterating through all cursors in `<iostream>` and computing the `repr` of all `cursor.location`s in there for different formatting methods. I actually found f-strings to be the slowest (~2.2s), old C-style formatting in the middle (~1.7s) and `str.format()` to be the fastest (~1.5s) although f-strings _are generally supposed to be the fastest_. In any case, the differences are not _massive_ and I would mostly ignore the performance PoV here

Other comments
- on `!r`: Reading https://peps.python.org/pep-0498/, the `!r` type conversion specifier has been around for a while, and it's only really supported because they wanted feature parity with `str.format()`. I'm personally not a big fan just because I don't usually see it, so I have to look up what it does every time. That might just be a me-problem though

https://github.com/llvm/llvm-project/pull/173861