Support puppet configuration through initializationOptions

[mehalter]

Use Case

The VS Code puppet extension is nice because it allows the use of the LSP settings table to configure the parameters used when starting the language server. This doesn't actually follow the official LSP specification and leaves other language server clients in other editors unable to utilize these options.

This also tightly couples the language server and the VS Code extension where default client settings are set in the language server:

puppet-editor-services/spec/languageserver/editor_client.rb

Lines 30 to 35 in d68eab4

	'puppet' => {
	'confdir' => '',
	'environment' => '',
	'modulePath' => '',
	'vardir' => '',
	'version' => '',

but these are features/options purely implemented in the VS Code extension. If there are changes to the VS Code extension, then it could force changes back to the language server for no real reason.

Describe the Solution You Would Like

Utilize the initializationOptions field in the InitializeParams part of the LSP spec (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize)

This will allow full configuration of the initialization of the language server without having to rely on building up argument lists. Adopting the official approach by the LSP specification would add many improvements:

• Decrease the complexity of the VS Code extension by removing the need to manually construct argument lists for initializing the server
• Decrease the tight coupling between the VS Code extension and the puppet-editor-services
• Make configuration both easier on the user by not relying on managing arbitrary string concatenation for configuration
• Enable other editors to easily configure the initialization parameters such as modulePath and environment
• Allow sharing initialization parameters between different editors with language server support
• Increase maintainability down the road if new initialization parameters are introduced