Altinn 3 language server

### Description

We currently use JSON Schema to assist app developers who work on Altinn 3 apps locally. This is nice enough, and gives you some level of autocompletion and validation, but it's far from perfect. Some examples of what isn't possible with a schema:

1. We can't check if components you add to (for example) `"children": [...]` exists, and we can't give you auto-completion/suggestions for which components you might want to add.
2. It's fully possible to configure something 'illegal', such as adding `InstantiationButton` to a stateful layout.
3. We can't give you autocompletion for paths in a data model (when setting them in, for example, `dataModelBindings`), and we can't validate them if you get them wrong.
4. Even things that should be possible using schemas ([such as validating that you've added a minimum number of arguments to an expression function](#1987)) isn't possible in practice, as long as we're misusing schemas (primarily meant for validation) as a source of autocompletion.

We could still rely on schemas for most things, but there are definitely things (such as those above) we could implement in a language server instead. With this running we could give the user much more intelligent and context-aware auto-completion, validation and help while developing an app locally (not in Studio).

We want to implement (and have implemented) some validation for misconfiguration already, so giving this info straight in the code editor/IDE would be even better.

### Related issues
- #648

### Additional Information

_No response_

Start by reading the existing JSON Schema approach, the validation for misconfiguration, and related issue #648. Scope the language server around the listed component, stateful-layout, data-model-path, and expression-function cases. Done means local app developers receive context-aware completion, validation, and help in their editor or IDE.

Written by the indexing model from the issue text.