I suspect that we don’t wait for `TestSourceKitLSPClient` to finish deinitializing (and thus waiting for the shutdown response) when we destroy it in `tearDown` based on the logs in https://ci.swift.org/job/oss-swift-incremental-RA-macos-apple-silicon/9004 (rdar://160344405).
Since I generally dislike the `setUp` and `tearDown` methods and we have `CustomBuildServerTestProject` now to model a setup of a SourceKitLSP server with a custom build server, use that instead of manually hooking up the build server through a workspace.
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
