Store EditorConfig in prisma-fmt

[pimeys]

For the code actions, we need to know what is the tab size, is the file using spaces or tabs and what kind of newlines are used. In the editor this is either a global setting, or per file.

Currently we sniff the datamodel and detect the settings, but The Real Way (tm) is for the language server to do a Configuration Request to the editor, which replies with the configuration. The configuration from the editor is not defined in the language server protocol, but should follow the EditorConfig standard.

We already did some tests with @Jolg42, and the editor sends back either a subset of this document or the whole thing, depending what gets requested. We should store the settings we need in memory for the file(s) and load the information to code actions when we need it.

[Jolg42]

but should follow the EditorConfig standard.

From what we could see, it doesn't follow it. See LSPAny[]

A ConfigurationItem consists of the configuration section to ask for and an additional scope URI. The configuration section asked for is defined by the server and doesn’t necessarily need to correspond to the configuration store used by the client. So a server might ask for a configuration cpp.formatterOptions but the client stores the configuration in an XML store layout differently. It is up to the client to do the necessary conversion. If a scope URI is provided the client should return the setting scoped to the provided resource. If the client for example uses EditorConfig to manage its settings the configuration should be returned for the passed resource URI. If the client can’t provide a configuration setting for a given scope then null needs to be present in the returned array.

Response:

result: LSPAny[]
error: code and message set in case an exception happens during the ‘workspace/configuration’ request