The diagnostic group documentation now point to the swift.org URL rather
than the toolchain path, so it no longer needs to be passed all the way
through sourcekitd.
Resolves rdar://151500502.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
It appears that a6ebd3083d changed the behavior of `-fno-modules-validate-system-headers` (aka. `DisableModulesValidateSystemDependencies`) in conjunction with `-fmodules-validate-once-per-build-session`: Before that change, `-fno-modules-validate-system-headers` needed to be passed for `-fmodules-validate-once-per-build-session` to have any effect (we were always validating system dependencies if `-fno-modules-validate-once-per-build-session` was not set). After the change, `-fno-modules-validate-once-per-build-session` causes system dependencies to never be validated, independent of the build session timestamp.
This change should have no effect on Xcode because it adds `-fmodules-validate-system-headers` to the compiler arguments for Swift files, which overrides `SearchPathOpts.DisableModulesValidateSystemDependencies = true;`
Driver uses its path to derive the plugin paths (i.e.
'lib/swift/host/plugins' et al.) Previously it was a constant string
'swiftc' that caused SourceKit failed to find dylib plugins in the
toolchain. Since 'SwiftLangSupport' knows the swift-frontend path,
use it, but replacing the filename with 'swiftc', to derive the plugin
paths.
rdar://107849796
