[CMake] Use separate namespace for demangling symbols used by runtime

This matches the behavior introduced with #30733 -- quoting the
explanation here for the sake of convenience:

> Since libDemangling is included in the Swift standard library,
> ODR violations can occur on platforms that allow statically
> linking stdlib if Swift code is linked with other compiler
> libraries that also transitively pull in libDemangling, and if
> the stdlib version and compiler version do not match exactly
> (even down to commit drift between releases). This lets the
> runtime conditionally segregate its copies of the libDemangling
> symbols from those in the compiler using an inline namespace
> without affecting usage throughout source.

Addresses rdar://142550635

Author: edymtt

Runtimes/Core/Demangling/CMakeLists.txt

@@ -16,6 +16,13 @@ target_compile_definitions(swiftDemangling PRIVATE
   $<$<BOOL:${SwiftCore_ENABLE_CRASH_REPORTER_CLIENT}>:-DSWIFT_HAVE_CRASHREPORTERCLIENT>
   $<$<BOOL:${SwiftCore_HAS_ASL}>:-DSWIFT_STDLIB_HAS_ASL>)
 
+# Target libraries that include libDemangling must define the name to use for
+# the inline namespace to distinguish symbols from those built for the
+# compiler, in order to avoid possible ODR violations if both are statically
+# linked into the same binary. (see also commit message for 5b1daa9055c99904c84862ecc313641fd9b26e63)
+target_compile_definitions(swiftDemangling PUBLIC
+    $<$<COMPILE_LANGUAGE:C,CXX>:-DSWIFT_INLINE_NAMESPACE=__runtime>)
+
 target_include_directories(swiftDemangling
   PRIVATE
     "${SwiftCore_SWIFTC_SOURCE_DIR}/include"

Runtimes/Core/runtime/CMakeLists.txt

@@ -95,7 +95,8 @@ target_include_directories(swiftRuntime PRIVATE
 
 target_link_libraries(swiftRuntime PRIVATE
   $<$<PLATFORM_ID:Windows>:User32>
-  swiftShims)
+  swiftShims
+  swiftDemangling)
 
 # FIXME: Refactor so that we're not pulling sources from the compiler files
 target_sources(swiftRuntime PRIVATE