Replace usages of `Optional.map` and `Optional.flatMap` by if expressions or other expressions.
I personally find `Optional.map` to be hard to read because `map` implies mapping a collection to me. Usually the alternative constructs seem clearer to me.
If a workspace was opened as `/path/to/workspace` instead of `/path/to/workspace/` (notice the trailing slash), the check for `url.deletingLastPathComponent() == self.projectRoot` failed because deleting the last path component always produces a URL with a trailing slash and URL considers two path different if they mismatch in their trailing slash usage.
Use `DocumentURI` for equality checking, which is a little more lenient with declaring equality, including with regard to trailing slashes, and whose equality definition aligns better with what we want in SourceKit-LSP.
I searched for other usages of `==` between URLs and there doesn’t seem to be any similar issues.
When I added the log structure to `build/logMessage` in #2022 I must have assumed that the entire BSP notifciation was an extension defined by SourceKit-LSP and didn’t realized that this was actually a change that made the notification non-compliant with BSP. Change it up a little bit to make it compliant again.
Two improvements to the logic that determines if we need to reload the package on a file change:
1. Only reload a package if the modified package manifest or Package.resolved is in the root of the package folder. This is relevant if we have a multi-root workspace, in which currently a single change to a package manifest or Package.resolved causes all packages to get reloaded.
2. While I was at it, I noticed that we didn’t properly handle version-specific package manifests. Also trigger a package reload if a version-specific package manifest is modified, created or deleted.
We already had logic to retry loading a package manifest if writing the output-file-map failed. This only covered errors thrown from Foundation but I was seeing similar errors from TSC. Cover those as well.
If a call in `reloadPackageAssumingOnPackageLoadingQueue` throws, we weren’t getting to the end of it and would thus never end the signpost started within. Move the `endInterval` call up ensure it is always ended.
Found this while investigating https://ci-external.swift.org/job/swift-PR-windows/44247/console, which failed SourceKit-LSP testing because PackageA could not be loaded due to
```
Initial package loading: invalid access to C:\Users\swift-ci\jenkins\workspace\swift-PR-windows\build\tmp\lsp-test\924F7085\PackageA\.build\index-build\x86_64-unknown-windows-msvc\debug\MyLibrary.build\output-file-map.json
```
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.
