Allow user specified exclusion patterns

[stevenrchun]

Reads initialization options for additional patterns to exclude from source files.

#560 demonstrated that users need to be able to specify patterns to exclude and that hardcoding it forever probably wasn't sustainable. So this makes it configureable.

It seems to me the initialization options is the most natural place to do this (rather than the settings configuration, for example). Similar to adding workspace roots, the user provided exclusions are provided to SourceFiles at initialization time.

This probably merits updating the documentation, but since I'd also like to improve the neovim documentation anyway I'll probably do that in another PR (mainly, there's no documentation that you need to have a "kotlin" object under settings, since the configuration parser is tailored to the configuration response that VSCode gives).

For example, in my neovim init.lua I'd write

vim.lsp.start({
	name = "kotlin-language-server",
	cmd = {
		...
	},
	filetypes = ....
	root_dir = ...
	init_options = {
		storagePath = ....,
		additionalSourceExclusions = { "new", "source", "exclusions*" },
	},
	settings = {
		kotlin = {
			scripts = {
				...
			},
			completion = {
				...
			},
		},
	},
})

[stevenrchun]

@fwcd I'm not sure if there are any additional actions I need to take (the labeling github action didn't seem to apply any labels to this PR) but this PR should be ready for your review.

[fwcd]

Thanks, left a few notes below

[fwcd]

Can we refactor this to use immutable lists?

Mutable structures make it harder to reason about where updates are happening and passing them around make it easier for things to get out-of-sync, therefore I usually prefer the functional style.

[fwcd]

Style nit:

Suggested change

	private var exclusions = SourceExclusions(
	workspaceRoots,
	scriptsConfig,
	additionalSourceExclusions
	)
	private var exclusions = SourceExclusions(
	workspaceRoots,
	scriptsConfig,
	additionalSourceExclusions
	)

[fwcd]

I'm not sure about whether we should put this into the initialization options. That makes it a bit more cumbersome on the VSCode side and I think it could be nice (in the future) if these options could be updated while the language server is running, even if we don't fully support "hot" configuration updates yet.