[clang] clang_EvalResult_getAsCXString impl (PR #134551)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> We could keep `CXString` as it was before, but `const void *data` could actually point to a dynamically allocated struct that has roughly this definition:
> 
> ```c
> struct Data  {
>     size_t length;
>     char data[1];
> };
> ```
> 
> This wouldn't change the current API, and it would still be only one allocation. What do you think?

It means all such string accesses would require two indirections to get to the string data, but that may be acceptable overhead (we probably should measure though, given how much string processing happens in tooling). I also wonder if we want to be slightly less memory efficient and add a `version` field in case we need to make changes again in the future (the only revision I can think of right now has to do with encodings, but we always use a single charset internally (UTF-8) so I don't know that we'd ever start returning multiple different encodings within the same program such that we'd need to track it on the string).

CC @cor3ntin who thinks about strings more than most folks do, so he may have opinions or ideas

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