When `DYLD_(FRAMEWORK|LIBRARY)_PATH` is set, `dlopen` will first check
if the basename of the provided path is within any of its search paths.
Thus it's possible that only a single library is loaded for each
toolchain, rather than a separate like we expect. The paths should be
equal in this case, since the client plugin is loaded based on the path
of `sourcekitd.framework` (and we should only have one for the same
reason). Allow this case and just avoid re-initializing.
There is only one real class that implements the `SourceKitD` protocol, so there really isn’t any need for the protocol + class split at all. Unify them to make code simpler to reason about.
We need to jump through a few extra hoops when the SourceKit plugin is located in SourceKit-LSP’s build folder and we are using `sourcekitd_plugin_initialize` instead of `sourcekitd_plugin_initialize_2`.
This adds a sourcekitd plugin that drives the code completion requests. It also includes a `CompletionScoring` module that’s used to rank code completion results based on their contextual match, allowing us to show more relevant code completion results at the top.
