[clang] [clang] Fix handling of asm string literals (PR #169803)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > > As to why we want to upstream this, any users of the upstream compiler would need this change to work on z/OS.
> > 
> > 
> > Any user, really? As best I can tell, this is only for some very specific situations, not for inline assembly in general? (I'm not familiar with the code patterns you're having to deal with; if this is needed by ~100% of folks, that's very different from if it's needed by ~1% of folks.)
> 
> Full inline assembly support on z/OS depends on this change. We also plan to upstream [#pragma map](https://www.ibm.com/docs/en/open-xl-c-cpp-zos/2.2.0?topic=sp-pragma-map) after this, which is functionally equivalent to asm labels and is used extensively in the z/OS system headers. Both asm strings and #pragma map symbol names frequently contain EBCDIC escape sequences to handle variant characters across EBCDIC code pages, so both must follow the same string parsing and encoding rules.

Thank you for the context! If this is required for supporting system header code, I think we'll probably have to hold our nose on it. However, one of the test cases still worries me greatly:
```
constexpr string_view getfoo() { return "\174foo"; }

void function()
{
  asm((getfoo()));
}
```
If I understand correctly, this is demonstrating the problem I raised before where the literal encoding depends on context. e.g., the call to `getfoo()` within `asm` will be using a different encoding than calling `getfoo()` in another context, or am I wrong about that?

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