(super minor) null dereference that looks like a gap in openmp's target validation

I've been trying to build a fuzzer that is similarly effective to the llm fuzzers, without all the obnoxious llm involvement and it's actually finding things, albeit dumb ones :D

This case looks like a build config validation issue, the test case is

```cpp
// test.cpp
unsigned i = __builtin_signbit(-0.0L);
```
Compiled with `clang -cc1 -fopenmp -triple arm64-apple-macosx -fopenmp-is-target-device test.cpp`

My suspicion is that the -cc1 path is assuming that that state was already validated on the driver side, because a non-cc1 invocation rejects with errors.

The crash itself comes from this path in getFloatTypeSemantics:

```cpp
case BuiltinType::LongDouble:
if (getLangOpts().OpenMP && getLangOpts().OpenMPIsTargetDevice)
return AuxTarget->getLongDoubleFormat();
```

because AuxTarget is null (once again indicating just a bogus build config)

Start by reproducing the reported command with test.cpp, then inspect the getFloatTypeSemantics path for BuiltinType::LongDouble and compare it with the non-cc1 invocation. Done means the invalid OpenMP target configuration no longer crashes and its behavior is covered by a regression test.

Written by the indexing model from the issue text.