Allow exclusion of sourcekit-lsp workspaces.

[GeorgeLyon]

Is your feature request related to a problem? Please describe.
A VSCode workspace may contain multiple sourcekit-lsp workspaces. To be specific, by "VSCode workspace" I mean the folder you are opening in a VSCode window and by "sourcekit-lsp workspace" I mean the workspaces managed by sourcekit-lsp (which effectively tells the LSP server where to search for Package.swift or compile_commands.json). As I understand it, this VSCode extension automatically tries to find a workspace when a Swift file is opened in the VSCode UI, and there is no way to influence this behavior. The one customization option provided is "search subfolders for packages", which tries to identify workspaces when the extension starts up.
This is fine for most projects, but there are times when this is problematic. One example is a project with a top-level Package.swift file (the "user-facing package") may have a number of other packages in its directory tree (packages testing the user-facing package, local packages that can be referenced by the user-facing package, or just one-off examples). I've noticed a number of weird issues in such a project, including some failures with package resolution (which can be disabled via an option) and LSP functionality being unavailable for the nested packages.

Describe the solution you'd like
For my example above, just deleting the top-level Package.swift fixed all my issues (i.e. LSP began working well in the nested packages). It would be great if there was a setting like the following:

"swift.sourckit-lsp.workspaces.exclude": [
  ".": true,
  "my/other/problematic/package": true,
  "test-workspaces/*",
]

Note that in this case a workspace located at "the/workspace/I/care/about" would still be enabled even though it is nested under ".", which is excluded. Support for "*" would be nice for folders of test projects.

[tamird]

Possibly related to this feature request: opening a workspace that contains non-swift compile_commands.json breaks in the presence of this extension. I don't have a small example, but if you download Fuchsia and run fx set you'll have generated a compile_commands.json; if you open that workspace in the presence of this extension you'll see that just about all C++ tooling is broken.

[rbenegal]

I can take a look a this.

[rbenegal]

Not currently looking into this, but when someone does look into this: Another use case mentioned in #1545 is that folks may want to use their compile_commands.json file instead of Package.swift. Currently it's possible to use sourceKit settings to do this, but would be nice if we are smarter/provide more options for compile_commands.json files, non-swift compile_commands.json files and Package.swift files.