[NFC] A trio of patches to improve incremental build times and compiler abstraction

[rjmccall]

Incremental improvements to the runtime — at least the ones I make :) — often add new things to Runtime/Config.h and ABI/MetadataValues.h. Currently, MetadataValues.h is included by TypeLowering.h, which is ubiquitously included by SILGen and everything afterward, so editing it requires rebuilding all that.

1. Split the one pertinent declaration out into its own file and make TypeLowering just include that.
2. That file includes a helper function that uses swift_runtime_unreachable, which is a layering violation. Fix it by moving Unreachable.h into Basic, renaming the function to swift_unreachable, and making it forward to llvm_unreachable (which is generally superior) whenever we're building with LLVM support, which we indicate with a new -D flag within the appropriate lib/ directories.
3. Move some of the attribute macros from Runtime/Config.h to Basic/Compiler.h so that we don't have to include Config.h just to get compiler abstraction.

[rjmccall]

@swift-ci Please smoke test.

[compnerd]

Why not instead of this just forward to __swift::__runtime::llvm_unreachable instead of llvm_unreachable? We should have that in the LLVMSupport in the runtime as well (or can be trivially restored).

[rjmccall]

We have a lot of code in headers, some of which can be usefully included in multiple environments: the compiler (which links LLVM support), the runtime (which can have a limited support library), and various other tools (which we generally shouldn't add linker assumptions to). This define tells those headers which environment we're in so that they can use the best implementation mechanism for that environment. This means that in code we can provide a single interface that works anywhere instead of expecting clients to carefully pick which interface they use; for example, it's now always fine to just use swift_unreachable.

I think what you're suggesting doesn't address that problem at all, because we'd be assuming the existence of a swift::runtime::unreachable. Without some level of configuration awareness, that actually makes the problem worse, because we'd have to actually put that function somewhere that gets linked into everything. Whereas if we want the runtime to have a better unreachable implementation than the current non-LLVM one, we could certainly just extend my approach to pass -DSWIFT_RUNTIME_SUPPORT_IS_AVAILABLE and make Unreachable.h take advantage of that.

[compnerd]

I was suggesting that for anything in stdlib, swift_unreachable just maps to __swift::__runtime::llvm_unavailable which is part of stdlib/LLVMSupport and for the compiler we just use llvm_unreachable from LLVMSupport which is linked against anyways.

[rjmccall]

1. Not everything in stdlib/ is linked into the runtime. It might be linked with the runtime, but we don't want to export symbols like this from the runtime.
2. I'm pretty sure that not everything in lib/ is linked with LLVMSupport.
3. The whole point of the cmake stuff here is telling the compiler what kind of thing we're building as part of, because that's not currently passed down in any other way that I can see.