[llvm] [llvm] Fix string and Twine concatenation for C++26 P2591R5 (PR #227959)

[James Henderson via llvm-commits]

https://github.com/jh7370 commented:

I'd be surprised if any of the new `#include "ADT/Twine.h"` headers are needed: LLVM has a policy of minimal includes in its coding standards, i.e. we don't need to explicitly include Twine.h if another header that is included includes it.

A note on the PR description:
>  chained with `.str()` such as `(Prefix + Name).str()`
This bit is actually irrelevant to the issue, so I'd look to omit it to avoid confusion. It's just that it's the most common pattern. Without the `.str()`, we'd still call the corresponding `operator+`, leading to issues in C++26.

I accept that this solves the problem we're facing, but I can't help but feel that there might be a better way of solving it that doesn't require changing every call site and I think we should look at what we can do to make that possible. Since adding another overload doesn't help as you've previously stated, how much churn does removing the `StringRef` to `std::string_view` conversion cause? Presumably this would remove the ambiguity, because then the new `operator+` added by the standard will not be compatible with `StringRef + std::string`. Assuming this does actually work with minimal churn, it would be worth a wider discussion to decide if this is the right thing to do or not. If it doesn't work, what other options do we have?

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