[clang] [Driver] Disable sanitizer ignorelists on Darwin (PR #195690)

[Andrew Haberlandt via cfe-commits]

ndrewh wrote:

> @ndrewh can you ELI5 what these problems are?

Problem 1: The ignorelists are not available when the swiftlang clang importer runs

The Swift clang importer is like TAPI in the sense that it automatically generates interfaces from C headers (see [2018 LLVM Developers’ Meeting: S. Wu “Using TAPI to Understand APIs and Speed Up Builds”](https://youtu.be/B9li6EkD5zA?t=181)). Importantly, this step happens before any dylibs have been built (including the Darwin sanitizer dylibs). If we are to honor the ignorelists during this step, it needs to be possible to build them separately from the dylibs.

A legitimate question is *do* we need to honor ignorelists during that step, or can we safely ignore the ignorelists? The main concern is whether the ignorelists can or will ever allow for conditionalized definitions i.e. with `#if __has_feature(address_sanitizer)`. It's not immediately obvious if the existing ignorelist allows for this (and it seems somewhat difficult to enforce the invariant that ignorelists can never change an interface in any way).

Problem 2: The swiftlang clang importer has a bug when CAS is enabled

The clang importer is using compilation caching via the dependency scanner implemented [here](https://github.com/swiftlang/swift/blob/54d06487c675a6775f201a2841c67594994a00f5/lib/DependencyScan/ModuleDependencyScanner.cpp#L475). This has a bug where it doesn't capture the dependency on the ignorelists when compiling with `-fsanitize=`. 

I am willing and able to just go and fix this bug, provided that we solve Problem 1.

----

Because Darwin does not use (or have any use-case for) the ignorelists, my preferred solution is to just stop using sanitizer ignorelists on Darwin, so that's what I proposed here.

The other solution I could imagine is relocating the ignorelists such that they can be built independently of the runtime dylibs:
- One option is to move them to `clang` (#195396)
- Or we could move them to a dedicated directory in compiler-rt such that they have their own target
- Or we could write a bunch of cursed CMake to make them buildable independently of the runtimes in their current locations in compiler-rt

If we follow through with moving them somewhere that they can be built separately, I think we can leave them on for Darwin and I can just go fix the downstream bug.

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