Remove non-standard nothrow specializations

[minchopaskal]

Fix for #7098
The specialisations of is_nothrow_constructible in StringRef.h are non-standard and as seen in the issue fail with newer versions of libc++.
Manage to compile on MacOS 26.4(clang-2100.0.123.102). The static checks in DiagnosticIDs.cpp remain though so if there is an issue the builds should show it.

[damyanp]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[damyanp]

It looks like the code is removed in this PR was very deliberately added. Before we can accept this, we'd need to understand that removing it doesn't regress the scenario it was intended to fix.

[minchopaskal]

@damyannp I don't plan on signing the CLA and I see there's already a PR about this with maybe less destructive solution - #8307

As for this

It looks like the code is removed in this PR was very deliberately added

1. First of all, the static assertions that is_nothrow_constructible<std::string, StringRef(&)>::value == 0 are still inside the DiagnosticIDs.cpp and I see all the builds succeed hence compilers already recognise this behaviour without the explicit specialisation (I want to repeat these specialisation are UB according to the c++ standard - search for behavior is undefined).

2. My best bet (but I can't prove that) is when Additional fixes for error handling exposed by OOM testing #425 was added some compiler had a bug that used the wrong specialisation of std::pair's constructor (specifically the pair<U&&, T&&> constructor) which expects to be inside a nothrow environment as move constructor of std::string is nothrow. In reality a new std::string is constructed(via StringRef::operator str()) and it can throw with std::bad_alloc. This could be tested with modifying the code in StringRef::operator str() to throw std::bad_alloc, although I don't have time to get familiar enough with DXC's codebase to test that.

Closing the PR.